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COPERNICUS is the Navy's Cl architecture envisioned to 
enhance command and control for the Composite Warfare 
Commander (CWC) , Fleet Commanders-in-Chief (FLTCINCs) and, 
eventually. Unified CINCs. The Communication Support System 
(CSS) is both a system and architecture that will be 
instrumental in the realization of the Copernican TADIXS 
networks. The purpose of this thesis is to provide operations, 
communications and management personnel sufficient information 
regarding COPERNICUS and the CSS in order for them to have a 
basis for planning and managing CSS operations at its 
implementation . 
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INTRODUCTION 



COPERNICUS is the Navy C 4 I architecture visualized as an 

interactive framework that will tie together the command and 

control process of the Navy tactical commander afloat, the 

Joint Task Force (JTF) commander, the numbered fleet commander 

and others with the CINCs ashore [Ref. l:p. 3-1]. It will 

consist of four principal segments, or pillars: the Global 

Information Exchange Systems (GLOBIXS) , CINC Command Complex 

(CCC) , Tactical Data Information Exchange Systems (TADIXS) , 

and Tactical Command Center (TCC) . By making use of the 

newest communications and computer network technology, it is 

2 

intended to see Command and Control (C ) into and through the 
21st century. 

The Communications Support System (CSS) will allow the 
tactical commander, through the Space and Electronic Warfare 
Commander (SEWC) , to control Copernican TADIXS in the same 
manner that other commanders control ASW, ASUW or AAW [Ref. 
l:p. 8-11], Thus, CSS is to become an integral part of the 
COPERNICUS architecture. With an Initial Operational 
Capability (IOC) of FY94, CSS is planned to route data between 
the TCC afloat and the CCC ashore. At its IOC, the Navy EHF 
Communications Controller (NECC) is a system that will operate 
under CSS with the new Navy EHF Satellite Program (NESP) 
terminals at a speed of 2.4 kbps. Thus, EHF satellite 
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communications (SATCOM) will become the first bearer service, 
or communications medium, to be provided as a Copernican 
TADIXS. Additional bearer services such as UHF, SHF, HF and 
commercial satellite communications (SATCOM) are also planned 
for incorporation into CSS. 

Although COPERNICUS intends that the "command and control 
universe" revolve around the tactical commander, the Fleet 
Commander-in-Chief (FLTCINC) retains overall responsibility 
for operations within his Area of Responsibility (AOR) , both 
as Naval FLTCINC and as component commander to his Unified 
CINC. This thesis is intended to provide an informational 
document for FLTCINC staff planners, operators, communicators 
and intelligence personnel alike so that they may gain a 
better understanding of the CSS and NECC, and of how these 
systems will work together toward fulfilling the plans 
conceived in the COPERNICUS architecture. 

This thesis is also intended to provide the FLTCINC, 
numbered fleet commander and other cognizant organizations a 
basis for discussion in managing CSS and NECC at IOC for 
communications planning purposes. Ideas will be presented so 
that use and management of these systems within a FLTCINC' s 
AOR may be determined and promulgated prior to the systems' 
IOC. Security issues will not be addressed in this thesis. 

For the purpose of simplification, a top-down discussion 
of the Copernican structure and how each system fits into the 
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larger picture will be presented. The following paragraphs 
delineate subjects which will be discussed by chapter. 

Chapter II will briefly describe the COPERNICUS 
architecture and its four pillars as currently envisioned. A 
short discussion of the SEW concept is included. TADIXS and 
its relationship to the CSS will be introduced to the reader. 

Chapter III will discuss CSS. Discussion will include a 
more detailed description of its functions and segments, and 
the capabilities it is planned to provide. Its relationship 
to COPERNICUS and its benefits to C 2 will also be covered. 

Chapter IV will describe the NECC. Included are 
discussions on EHF communications today, NECC ' s relationship 
to CSS, its functions, segments, and the capabilities it is 
planned to provide at IOC. NECC applications both in the near 
and far term will be presented. An appendix to the thesis 
provides a schedule of the capabilities planned to be provided 
by the NECC in the future. 

Chapter V will bring together the previous discussions 
with a description of the NESP terminal in order to develop a 
CSS communications plan (COMMPLAN) and a CSS connection plan 
( CNCTNPLAN) . A planning approach will be explained in order 
that planners may get an idea about CSS communications 
planning prior to IOC. Issues will be identified that may 
require discussion prior to CSS/NECC implementation. 
Recommendations will be made as to how those issues might be 
resolved . 
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A brief summary and 



Chapter VI concludes the thesis, 
recommendations will be presented. 
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II 



THE COPERNICUS ARCHITECTURE 



A. PURPOSE 

The tremendous growth of Navy telecommunications, the 
increase in demand by its users and the acknowledgment of its 
critical role m supporting command and control (C ) have 
resulted in the identification of three major problems with 
the current Navy telecommunications system [Ref. 2:p. 2]: 



• Limited ability to separate critical sensor and 

operational traffic from mission support and/or 

administrative traffic . During conflict, decision makers 
must receive only the information they require in order to 
plan their actions. Administrative traffic competes with 
those messages whose timely delivery is crucial to 
successful operations. 

• Overreliance on narrative message traffic and the lack of 

common information formats inundate the warfiahtina 
commander in data that cannot be readily assimilated and 
used . Precious time is often wasted in either 

interpreting or sorting through information from numerous 
sources in order to make a critical decision. 

• Limited technical oversight of today’s Command. Control. 
Communications. Computers and Intelligence fC iT 
architecture . Separation and lack of coordination among 
Naval C I components, as well as joint and allied 
components, often lead to duplication of effort, overtaxed 
communications resources, interoperability and security 
issues . 



Additionally, with the mafesive amounts of information to 
be processed, reduced manning, and the complexity and 
sophistication of emerging systems, new computer architectures 
and applications will be required [Ref. 2:p. 14]. Only an 
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improved information management system that is state-of-the- 
art and can keep up with rapidly developing technological 
advances in telecommunications can remedy these problems. 

. . 4 

In order to achieve a cohesive C I architecture that will 
fully support C 2 , the COPERNICUS architecture has been 
defined. COPERNICUS will be constructed as an interactive 
framework that ties together the command and control process 
of the Navy tactical commander afloat, the Joint Task Force 
(JTF) commander, the numbered fleet commander, and others with 
the CINCs ashore [Ref. l:p. 3-1]. It is also planned to 
support joint and Allied operations in the future. 

B. THE SEW CONCEPT 

The Warfare Mission Area (WMA) of Space and Electronic 
Warfare (SEW) was established in 1989 by the Chief of Naval 
Operations (CNO) . The WMA is seen as the Navy's commitment to 

. . 4 

bring together elements of Electronic Warfare (EW) , Cl, 

surveillance and other tactical and strategic assets into a 

seamless SEW system. Together with other warfare commanders 

such as the Anti-Air Warfare Commander (AAWC) , Anti-Submarine 

Warfare Commander (ASWC) , and Anti-Surface Warfare Commander 

(ASUWC) , the SEWC will provide support to the Composite 

Warfare Commander (CWC) . [Ref. l:p. 9-2) 

The SEWC's role is anticipated to become fully developed 
within approximately ten years. In support of this 
development, SEW doctrine is currently being established. A 
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SEW Naval Warfare Publication (NWP) is being produced, and SEW 
subsystems are being identified. COPERNICUS, a SEW subsystem 
intended to support all commanders, will be delegated to the 
SEWC by the CWC [Ref. l:pp. 9-2, 1-9]. 

C. THE FOUR PILLARS OF THE COPERNICUS ARCHITECTURE 

The COPERNICUS architecture will consist of four pillars: 
the Global Information Exchange Systems (GLOBIXS) , the CINC 
Command Complex (CCC) , the Tactical Data Information Exchange 
Systems (TADIXS) , and the Tactical Command Center (TCC) . 

1. GLOBIXS (Global Information Exchange Systems) 
a. Discussion 

The GLOBIXS are planned as worldwide or theaterwide 
limited access, high speed, highly concentrated virtual 
networks which will join shore-based commands or activities of 
like missions or interests [Ref. l:p. 4-1]. (A virtual 
network is one which exists only for the time it takes to 
exchange information among users.) Besides allowing GLOBIXS 
members to send information to other shore-based members, 
GLOBIXS will transport, standardize, and concentrate shore- 
based sensor, analytic, command support, administrative, and 
other information for further passage to commanders afloat 
[Ref. 1 : p . 4-1]. 

GLOBIXS terminal equipment are slated to consist of 
STU-IIIs and the Fleet All-Source Tactical Terminals (FASTTs) , 
Copernican standardized computer hardware [Ref. l:p. 4-15]. 
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The FASTTs of members of a particular GLOBIXS network will 
share the same application software, and will be linked to the 
FASTT of their corresponding Operations Watch Center (OWC) 
operator at the CCC [Ref. 3]. These operators, acting in 
accordance with tailored doctrine established by each Officer 
in Tactical Command (OTC) , will have the technological 
capability to determine whether and to what degree to filter 

shore-based information [Ref. 4:p. 90]. 

. . . 2 

The tailored doctrine will be a CWC's C plan, 

selected from matrices in a future COPERNICUS management NWP 
that will describe COPERNICUS GLOBIXS-TADIXS configurations 
[Ref. 3], The CCC personnel will consolidate, size, and 
format the shore-based information from the GLOBIXS and send 
it over the appropriate TADIXS [Ref. 4 :p. 90]. The 
collection of GLOBIXS information the CWC selects may be 
independent from that of another CWC in a different 
communications area (COMMAREA) . 

Thus, it may be stated that CCC personnel will 
anchor — filter, sort, analyze, and move — GLOBIXS information 
for the tactical commander, and that GLOBIXS should afford the 
Composite Warfare Commander (CWC) the capability to receive 
information tailored to his needs in order to fulfill his 
specific mission [Ref. l:p. 3-2]. If he so desires, the 
tactical commander may decide that some or all GLOBIXS 
information be anchored by afloat personnel, based on his 
personal preference [Ref. l:p. 3-13]. Figure 1 [Ref. l:p. 3- 
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4] illustrates how the CCC anchors will act as interfaces, or 
gateways, between the GLOBIXS and TADIXS virtual networks, 
taking information from their respective GLOBIXS networks to 
filter and consolidate it into a concise, uniform package that 
can be sent over the TADIXS to the TCCs. These personnel will 
similarly transmit "anchored” TADIXS information over their 
respective GLOBIXS networks [Ref. l:p. 3-2], 

Some programs related to GLOBIXS development are 
the Defense Data Network (DDN) , a worldwide digital packet 
switched network; the Defense Message System (DMS) , scheduled 
to replace AUTODIN; and the Defense Switched Network (DSN) , 
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the primary DOD telecommunications network which has evolved 
from the AUTOVON network. [Ref. l:p. 4-24] 
b. GLOBIXS Networks 

As stated previously, the GLOBIXS are intended to 
join shore-based commands of like missions or interests. 
Eight GLOBIXS networks are initially planned. Five GLOBIXS 
are operationally oriented and contain the major sensor and 
analytic nodes, both Navy and national: 

• GLOBIXS A for Signals Intelligence (SIGINT) ; 

• GLOBIXS B for Antisubmarine Warfare (ASW) ; 

• GLOBIXS C for Space and Electronic Warfare (SEW) ; 

• GLOBIXS E for Imagery; and 

• GLOBIXS F for Data Base Management (where files may be 
moved to and from TCCs) . [Ref. l:pp. 4-2, 4-19] 

GLOBIXS D will be a multimedia (video- 
teleconferencing, facsimile, secure voice) High Command 
(HICOM) network, connecting major commands such as the 
FLTCINC, Joint Task Force commander and numbered fleet 
commander [Ref. 3]. Its format will depend on the medium 
being used. 

The remaining two GLOBIXS will be primarily 
supportive in nature: 

• GLOBIXS G, the Research & Development Information Exchange 
System, which will provide for exchange of information 
among such organizations as Navy laboratories and weapons 
testing facilities 
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• GLOBIXS H, the Navy Information Exchange System (NAVIXS) , 
the Navy's implementation of the Defense Message System 
(DMS) , intended to support traditional narrative message 
traffic. [Ref. l:p. 4-2] 

The construction of a GLOBIXS is expected to be 
accomplished by little more than the connection of standard 
hardware onto a Defense Communications System (DCS) backbone 
at a proposed GLOBIXS node with tailored software applications 
[Ref. 3]. Therefore, a contingency GLOBIXS could be created 
to support no-notice operations if required. Similarly, 
additional GLOBIXS may be added to the architecture as the 
need arises. 

The use of COPERNICUS Common (COPCOM) , the Navy's 
planned binary digital format, and OPNOTE (a message format 
similar to that used by OTCIXS, the Officer in Tactical 
Command Information Exchange Subsystem) by net members of 
GLOBIXS A, B and C should provide true exchange of digital 
information [Ref. l:p. 4-16], characterized by voice, imaging 
and digital data, not principally character-oriented textual 
information such as the AUTODIN message format being used 
today [Ref. 3]. The use of digital information will increase 
message traffic speed and volume over those bearer services , 
in this instance DCS and commercial circuits, capable of 
supporting them. 
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2 . The CCC (CINC Command Complex) 
a. Discussion 

The CCC will include a number of existing 
organizations brought together technologically by common 
workstations (FASTTs) connected to a metropolitan area network 
(MAN) [Ref. l:p. 5-2]. The CCC MAN, like GLOBIXS, is a 
virtual network, part of the Base Information Transfer System 
(BITS) , a backbone scheme for basewide communications systems 
integration, which will interface to the DCS [Ref. l:p. 5-15]. 
The wideband CCC MAN will connect to many, smaller, local area 
networks (LANs) , also part of BITS, of those shore-based staff 
and command organizations whose information provides strategic 
and tactical mission support to the FLTCINC [Ref. l:p. 8-2]. 

CCCs will be located at Oahu, Hawaii, Norfolk, 
Virginia, and Naples, Italy, and will be managed by 
CINCPACFLT , CINCLANTFLT and CINCUSNAVEUR, respectively. Each 
CCC may be constructed differently. A LAN within each CCC 
will provide gateways to the larger MAN, connecting the 
centers and providing gateways to TADIXS through the 
Communication Support System (CSS) and to shore GLOBIXS 
networks [Ref. l:p. 5-6]. In other words, besides information 
generated by the CCC, both GLOBIXS and TADIXS information will 
travel over the CCC MAN. 

Much like GLOBIXS, the CCC MAN is also planned to 
be flexible and dynamic by allowing the FLTCINC the capability 



12 



to add or delete members from its configuration according to 
operational scenario. Thus, the CCC MAN would also be capable 
of incorporating compatible LAN(s) of the Unified CINC, 
converting itself from a Navy network to a Unified network in 
order to support any joint or allied operations or the 
eventual joint architecture. [Ref. l:p. 5-2] 

The WWMCCS ADP Modernization (WAM) , is a program 
under which current ADP systems are being redesigned and 
replaced. ASWOC Modernization is the installation of a LAN- 
based architecture at all ASW Operations Centers. Both 
programs are related to the development of the CCC, in 
addition to BITS. [Ref. l:p. 5-15] 

Jb. The Organizational Building Blocks of the CCC 

As previously discussed, it is planned that the CCC 
will have the capability to manage the flow of information for 
the tactical commander. Six organizational building blocks 
are planned to constitute the CCC [Ref. l:p. 5-4]. 

The Fleet Command Center (FCC) is the center of 
FLTCINC operations. In fulfillment of its duties to support 
the FLTCINC in the exercise of their responsibilities as naval 
component commanders, the FCC will manage theater resources, 
interface with designated net members for operational tasking 
and coordination and receive various informational reports as 
required [Ref. l:pp. 5-7 - 5-8]. The FCC may also communicate 
via the CCC MAN with the numbered fleet commander, CWC, 
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operational units, other FCCs and supporting CINCs. The FCC 
will anchor GLOBIXS D, the Command GLOBIXS. 

The Operations Watch Center (OWC) , whose membership 
will be controlled by the CCC, is designated to be the heart 
of the COPERNICUS architecture ashore, serving as the gateway 
for the CWC into the GLOBIXS organization. As previously 
mentioned, the OWC's operators and their FASTTs will be 
interactively connected to the watchstanders of the other 
organizational building blocks listed here, and can be viewed 
as a collection of GLOBIXS anchor desks and other personnel 
assembled to suit the mission being executed. OWC personnel 
will be a part of, and served by, the CCC MAN, rather than a 
physically co-located structure. In other words, anchor desks 
of the GLOBIXS networks will be situated at each of the other 
organization building blocks. [Ref. l:p. 5-4] 

The Space and Electronic Warfare (SEW) Center will 
be responsible for strategic and theater-level SEW, and is 
planned to anchor GLOBIXS C, and will act as the interface 
between GLOBIXS C and the SEW TADIXS [Ref. l:p. 5-5]. The SEW 
Center may also be delegated management functions of some or 
all TADIXS by the CWC [Ref. l:p. 6-13]. 

The Research Center will anchor and provide 
information retrieval capability for the CCC through GLOBIXS 
F, the Data Base GLOBIXS. It will also house common data 
bases for the CCC MAN. [Ref. l:p. 5-5] 
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The Joint Intelligence Center (JIC) will consist of 
the Fleet Intelligence Center (FIC) , which will anchor GLOBIXS 
E, and act as the interface between GLOBIXS E and TADIXS 
imagery; the Fleet Ocean Surveillance Intelligence Center 
(FOSIC) , providing operational intelligence (OPINTEL) ; and the 
Cryptologic Support Group (CSG) , which will anchor GLOBIXS A 
and act as the interface with both SIGINT GLOBIXS and TADIXS 
[Ref. l:p. 5-5]. Similarly, the ASW Centers will anchor 
GLOBIXS B and interface with both ASW GLOBIXS and TADIXS [Ref. 
l:p. 5-5] . 

As shown in Figure 2 [Ref. l:p. 8-1], the GLOBIXS 
and the CCC will comprise the shore side of information 
management in the COPERNICUS architecture. The final two 




Figure 2. The Pillars of the COPERNICUS Architecture 
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pillars of the architecture, TADIXS and the TCC, will 
constitute the afloat/air/ground warfighting portion. 

3. TADIXS (Tactical Data Information Exchange Systems) 
a. Discussion 

TADIXS are to be the virtual networks which will 
support afloat/ground/airborne Tactical Command Centers 
(TCCs) . TADIXS are envisioned as information nets time- 
sharing communications circuitry over a broad range of bearer 
services , transmission media such as UHF, SHF, EHF and 
commercial SATCOM and HF. The information of one TADIXS may 
be supported by several channels and, conversely, one channel 
may support several TADIXS [Ref. l:p. 6-1]. 

What percentage of time a TADIXS net will share 
with other TADIXS information and which medium will be used 
will be determined by the CWC, based upon the future NWP 
matrix previously discussed. The CWC may delegate the 
responsibility for management and control of the TADIXS to the 
SEW Commander (SEWC) or the SEW Coordinator [Ref. 2:p. 18]. 

TADIXS will be defined by five elements: 

• user software/data addressing , HMI software will provide 
TADIXS information to the appropriate afloat commander. 
In turn, that commander will address the information to 
the cognizant afloat FASTTs requiring that information. 

• format, either COPCOM or OPNOTE (digital) , narrative 
message (textual) , voice, or video 

• subscriber ship , both GLOBIXS and TADIXS members designated 
as net subscribers 
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• duration , either permanent, or a specified time frame 

• communications pathway, determined via the CSS, dependent 
upon available path, data format, degree of jam-resistance 
required, the capabilities of other TADIXS subscribers, 
and the duration of the TADIXS. [Ref. l:pp. 6-14 - 6-15] 

These capabilities will be afforded to TADIXS 
management by the CSS, which will provide the tactical 
transmission systems and the networking capabilities to 
support TADIXS communications services [Ref. 2:p. 5], CSS 
will provide the ability for the CWC (through the SEWC) to 
control Copernican TADIXS in the same manner that other 
commanders control ASW, ASUW or AAW [Ref. l:pp. 8-11]. CSS 
will be the framework for management of control of 
communications assets among TCCs. How this will be 

accomplished will be discussed in the next chapter. 

The TADIXS will enhance communications among TCCs 
and augment command and control capabilities: 



• by nearly eliminating the necessity for the narrative 
message through its use of binary data transfer (NAVIXS 
will still provide narrative message traffic) ? 

• by providing greater efficiency and communications 
capacity by its virtual networking and the use of software 
which will provide information (via high resolution 
graphics and imagery) more efficiently and powerfully than 
text ; 

• by allowing multimedia access via the CSS; and 

• by providing jam resistance capability. [Ref. l:p. 6-4] 



Some programs related to TADIXS development besides 
the CSS are the Advanced Narrowband Digital Terminal (ANDVT) , 
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which supports secure digital voice or data communications; 
Submarine Satellite Information Exchange Subsystem (SSIXS) II, 
an upgrade to the current SSIXS UHF SATCOM network; and the 
UHF Follow-on (UFO) Satellite System, designed to replace 
FLTSATCOM satellites. [Ref. l:pp. 6-15 - 6-17] 
b. TADIXS Categories 

All TADIXS, less NAVIXS TADIXS, are being designed 
in formats other than narrative messages [Ref. l:p. 6-2]. 
Four types, or categories, of TADIXS are planned [Ref. l:p. 6- 
1 ] : 



• Command TADIXS. These multiformatted TADIXS will support 
communications among higher level commanders (National 
Command Authorities, Unified CINCs, FLTCINCs, CWC) and 
those between the CWC and his subordinate commanders 
(Navy, joint or Allied) . 

• Support TADIXS. These TADIXS will include, for example, 
Logistics, Environmental, Data Base File Transfer and 
Imagery TADIXS. NAVIXS TADIXS is contained here as well. 
NAVIXS is anticipated to be the only TADIXS to support 
narrative message traffic. 

• Direct Targeting TADIXS. These TADIXS will be tailorable 
to specific geographic areas and can be modified for 
Allied usage. 

• Force Operations TADIXS. These TADIXS will be constructed 
around the tactical force. Their makeup will be dependent 
on that force, whether it be Joint Task Force ( JTF) , 
Carrier Battle Group (CVBG) or Marine Air/Ground Task 
Force (MAGTF) . 



4. The TCC (Tactical Command Center) 

A TCC will be defined by warfighting functions 
performed (e.g. , CWC/OTC, SEWC, ASWC) . Thus, one platform 
could have more than one TCC, and conversely, a single TCC 
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could be located on several platforms [Ref. l:p. 7-5]. It 
will consist of the tactical centers of a battle group 
commander, his units and command centers (each of these also 
considered a TCC) of multiforce commanders whether afloat, 
ashore or airborne, thus providing connectivity among all of 
its members. TCCs will be hierarchically determined according 
to operational plans for a mission [Ref. l:p. 7-6]. 

The future installation of LANs using fiber optic 
busses is intended to connect all operational spaces aboard 
ships [Ref. l:p. 7-2]. These afloat LANs, using FASTTs with 
application software similar to their counterparts ashore, 
will receive information via the TADIXS. This enhanced 
capability within the tactical commander's ship and within the 
ships of his subordinates, as well as the ability to configure 
his C system (receipt of external information) according to 
the needs of his mission, are expected to facilitate and 
improve his decisionmaking capacity. 

The Navy Tactical Command System Afloat (NTCS-A) is 
related to the development of the TCC. It is to be composed 
of such systems as the Joint Operational Tactical System 
(JOTS) ; the Electronic Warfare Coordination Module (EWCM) , 
which will provide planning, decision aids, and automated data 
processing support for the CWC/OTC and Electronic Warfare 
Coordinator (EWC) ; the Afloat Correlation System (ACS) , a 
near-real-time support system for automated correlation, 
fusion and other analytical manipulation of multisource threat 
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information; and the Naval Intelligence Processing System 
(NIPS) , which will support analysis packaging and distribution 
of intelligence information for the CWC/OTC and subordinate 
warfare commanders and coordinators. [Ref. l:pp. 7-10 - 7-11] 
Figure 3 [Ref. l:p. 8-2] should assist the reader in 




conceptualizing how the four pillars will interact 
technologically. The figure illustrates information 

technology ashore (GLOBIXS, CCC) and information technology 
afloat (TADIXS, TCC) . 

D. THE COPERNICUS C 2 DOCTRINE 

The COPERNICUS architecture aims to provide the CWC 

information improved both in accuracy and in timeliness, 

affording him the precision, time and options representative 
2 

of a C capability commensurate with today's ever-improving 
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technology. Upon implementation of the COPERNICUS 
architecture, the four pillars, their features and 
capabilities will provide the tactical commander with six 
doctrinal choices to make according to his mission [Ref. l:p. 
3-1] : 



• Selection of technological, doctrinal and organizational 
components of the TCC. That is, configuration of the TCC 
and the TCCs of his subordinate units to reflect the 
mission. 

• Determination of which GLOBIXS information will be 
anchored by CCC personnel and which, if any, by his 
personnel afloat. 

• Selection of desired GLOBIXS information by network and 
which cases (data precedences) will warrant receipt of 
that information. This option may be changed by the CWC 
in accordance with any changes in the mission. 

• Selection of communications services and addressing them 
to chosen units and TCC positions. 

• Selection of TADIXS mix: where information will be sent 
and how it will be displayed. 

• Selection via CSS of communications resources to support 
the TADIXS virtual networks. [Ref. l:p. 3-12 - 3-15] 



As previously mentioned, some of these functions may be 
delegated to the afloat SEWC or even the SEW center ashore 
[Ref. 1 : p . 6-13]. 

E. THE DEVELOPMENT OF COPERNICUS 

In the next decade, the accomplishment of four tasks are 
required to begin achieving the COPERNICUS architecture: 
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• Build GLOBIXS and the analytical tools which will be used 
by the networks ' users 

• Formulate and format the right mix of TADIXS 

• Construct the FCC, CCC and TCCs 

• Systemize our [SATCOM] constellations, develop a dynamic 
multiplexing system, and incorporate DDN ashore to build 
the architecture ' s communications backbone . [Ref. 4:p. 92] 

Additionally, planned TADIXS bearer services must be further 

developed so that they may provide the maximum amount of 

throughput [Ref. l:p. 6-9]. 

. 2 

Thus, the previously stated C enhancements will be 
realized incrementally, in concurrence with development of the 
COPERNICUS architecture. COPERNICUS development will be 
achieved in steps by implementation of various related 
systems. CSS, the initial implementation of Copernican 
TADIXS, will be discussed in the following chapter. 

F . SUMMARY 

. . 4 

In order to achieve a cohesive C I architecture that will 
fully support C 2 , the COPERNICUS architecture has been 
defined. COPERNICUS will be constructed as an interactive 
framework that ties together the command and control process 
of the Navy tactical commander afloat, the Joint Task Force 
( JTF) commander, the numbered fleet commander, and others with 
the CINCs ashore. COPERNICUS is intended to support all 
commanders, and will be delegated to the SEW Commander (SEWC) 
by the Composite Warfare Commander (CWC) . COPERNICUS 
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development will be achieved in steps by implementation of 
various related C4I systems. CSS will be the initial 
implementation of Copernican TADIXS chapter. 
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III. THE COMMUNICATION SUPPORT SYSTEM (CSS) 



A. THE CSS ARCHITECTURE 
l. Discussion 

CSS is more than a system. CSS is a communications 
sub-architecture that enhances battle force communications 
connectivity, flexibility and survivability through multi- 
media access and resource sharing. The CSS is to be an 
integral part of COPERNICUS. As shown in Figure 3, 
information will travel across the GLOBIXS, over the CCC MAN, 
and then to the CSS terminals located at TCCs via TADIXS. 
Conversely, information will travel from CSS terminals via 
TADIXS to the CCC MAN, then on to the GLOBIXS, thus providing 
the means for Copernican ship/ shore ship communications. [Ref. 
3] 

Like COPERNICUS, the CSS architecture is also 
evolutionary: it will achieve full realization incrementally 
by integrating existing dedicated communications systems and 
by implementing new systems to interface with it. The CSS 
architecture will also provide direction to the design of 
those new systems [Ref. 5:p. 2-2]. 

The CSS modular approach will reduce development and 
life cycle support costs of future systems substantially by 
the use of open system architecture principles [Ref. 3]. An 
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open system architecture provides interoperability between an 
existing system and new technologies. Thus, CSS will provide 
flexibility through reconfiguration of either CSS hardware or 
software, and an expansion capability to support new 
technologies as well [Ref. 6:p. 36]. CSS intends to 

accommodate system improvements with minimal disturbance or 
adjustment to what has already been implemented [Ref. 5:pp. 2- 
2 - 2-4] . 

The CSS will be the first implementation of the 
COPERNICUS architecture and, in turn, the Navy EHF 
Communications Controller (NECC) will be the first increment 
of the CSS architecture, providing an EHF SATCOM capability to 
the Copernican TADIXS. Initial Operational Capability (IOC) 
of NECC under CSS is scheduled for FY94. 

2. CSS Architectural Goals 

The operational and procurement goals of the CSS 
architecture are in accord with those of the COPERNICUS 
architecture, and aim to provide the tactical commander with 

. 4 ... • 2 . 

cost-effective C I capabilities necessary for proficient C m 
the future: 

• increased communications survivability via automated 
access for all users to multiple media, without 
sacrificing user throughput or communications efficiency; 

• increased responsiveness to rapid changes in warfighting 
information transfer requirements by permitting near-real- 
time reconfiguration of communication connectivity to 
support changing priorities of information exchange; 
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• means for incorporating new communications capabilities 
without requiring changes to the user's baseband equipment 
or operating procedures; 

• maximized use of existing communications equipment; 

• minimum impact upon funding profiles of existing and 
planned programs; 

• lower future communication system development and life 
cycle support costs ; and 

• simplified communication system operation and maintenance. 
[Ref. 5 : pp. 2-2 - 2-3] 

These architectural goals will be discussed in further detail 
at the end of this chapter. 

B. DESCRIPTION OF CSS 
l. css Components 

In order to discuss the functional capabilities of the 
CSS, it is important to have a basic understanding of the 
components which make up the system. The following defined 
terms will enable the reader to better visualize the 
connectivity CSS will provide among Copernican TADIXS network 
members . 

A CSS user is a communications device. A device may 
be a STU III for voice communications, a FASTT workstation, or 
a teletype (TTY) . CSS and its users will be located at the 
CCC, the SEW Center, where the CSS GLOBIXS/TADIXS interface 
will be managed, and aboard TCCs. 

A CSS subscriber is a device or software within CSS 
which interfaces directly between the user and the CSS 
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Standard Communications Environment Communications Services 
(SCE CS) , providing one or more users access to the CSS [Ref. 
5:p. 2-3]. (The SCE CS is a section of the CSS and will be 
described later in this chapter.) Using the previous example, 
a FASTT subscriber would allow a particular FASTT to interact 
with CSS; a TTY subscriber would allow a particular TTY to 
interact with CSS. 

A CSS service will be able to accept/deliver 
incoming/outgoing information to a common community of 
subscribers [Ref. 8]. A service is similar to a circuit; 
however, it is defined by factors more in keeping with the 
activation of a TADIXS virtual network: the time period the 
service will be available; type of information, or operational 
format (digitized data, voice, imagery) , which will be 
transmitted over the service and associated resources and 
access to these resources; security requirements; delivery 
characteristics of the service (time, degree of reliability, 
accountability) ; and the participants (subscribership) of the 
service [Ref. 7:pp. 5-6]. 

A CSS resource will consist of a CSS Subnet Access 
Control (SAC) segment, a CSS Link Access Radio Group (LARG) , 
and the transmission medium to which the information is 
applied [Ref. 6:p. 33]. (Descriptions of the SAC and the LARG 
are included in the CSS Software Segments section.) 

Resources are initially planned to provide data rates 
of 75 bps to 4.8 kbps. The NECC will operate at up to 2.4 
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kbps. Once additional SHF and commercial SATCOM terminals are 
fielded for the fleet, resources may provide up to 256 kbps 
[Ref. 8]; the incorporation of T1 rates (1.544 Mbps) into CSS 
operations is also planned for the future [Ref. 10]. 

2 . Multimedia Access and Resource Sharing 

CSS will allow one service to use more than one 
resource. This capability is termed multimedia access. 
Examples of this are a service that could be transmitted by 
one or more UHF SATCOM radios over several UHF frequencies, or 
a service that could be transmitted by one or more radios over 
separate frequency bands (e.g., EHF and UHF SATCOM). On the 
other hand, one resource may be used to support multiple 
services; this CSS function will be known as resource sharing. 
[Ref. 7 : p . 7] 

As shown in Figure 4 [Ref. 5:p. A-2], CSS will 

actually support four cases of service-to-resource matching: 

• one resource supporting one service 

• one resource supporting multiple services 

• multiple resources supporting one service 

• multiple resources supporting multiple services [Ref. 5:p. 

A-2] 

It is planned that each service may be assigned to as many as 
eight different resources, and that up to 16 services may be 
allocated to a single resource [Ref. 6:p. 23]. 
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Figure 4 . Matching Services to Resources 



The amount of resource usage allotted to each service 
will be determined by the service priority , data precedence 
(COPERNICUS architecture documentation refers to data 
precedence as "case") , and Percent Allocation of Resources 
(PAR) values defined in a CSS connection plan (CNCTNPLAN) or 
entered by the CSS operator. The CNCTNPLAN will be derived 
from a matrix incorporated into a future version of the NWP 
that will define services based upon Joint doctrine, 
USCINC/FLTCINC OPLANs and communications plans (COMMPLANs) 
[Ref. l:p. 6-3]. CNCTNPLANs will be discussed further in 
Chapter V. 

Because of these values, new users within a TCC will 
be accommodated on a priority basis. No new radios should be 
required to support a new user unless the total capacity for 
a platform is exceeded [Ref. 7:p. vi] . However, if a 
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platform's capacity were to be exceeded, CSS would facilitate 
effective communications management by using the service 
priority, data precedence and PAR values. A more detailed 
description of how these values are used is included in the 
next section. 

3. CSS Segments 

CSS's major functions are software, not hardware, 
related [Ref. 9]. Familiarity with its segments and their 
functions will facilitate further understanding of CSS and how 
it will provide multimedia access and resource sharing. 
Therefore, an overview providing brief descriptions of the CSS 
segments follows. 

a. The Hardware Segment 

The Communication Controller (CC) segment is the 
physical multiprocessor computer base in which CSS functions 
will be executed. All software segments will physically 
operate in one or more computers using technology similar to, 
but not limited to, the DTC-2 series [Ref. 3]. (The DTC-2 is 
a workstation for the Naval Tactical Command System (NTCS)). 
The current standard is the 680X0 series of multiple processor 
computers [Ref. 8]. 

The number of CCs on a TCC, or platform, will 
depend on the platform's physical layout/available space, or 
perhaps its requirement to support both Special Intelligence 
(SI) and General Service (GENSER) information security 
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requirements [Ref. 7:p. 39]. If there is more than one CC on 
a TCC, there will be communication between the CCs to ensure 
that all of the TCC's resources are shared among subscribers 
[Ref. 7 : p . 38]. 

Should CC failure occur, the TCC will have two 
options: continue to operate with the services established 
prior to CC failure; or revert to non-CSS operations, 
returning to nonvirtual circuitry through manual patching 
[Ref. 7:p. 38]. CSS-capable platforms will be able to 
communicate with non-CSS platforms (either US or allied) . In 
these instances, however, a service will require a single, 
dedicated resource without the use of CSS protocols [Ref. 7:p. 
7] • 

The CC will contain one or more central processing 
units (CPUs), memory, and input/output interfaces [Ref. 7:p. 
43]. Additionally, the CC will have some hard disk storage 
capacity and be modularly expandable to support system growth 
[Ref. 7 : p. 41]. 

b. The Software Segments 

As mentioned earlier, CSS's success and the bulk of 
its design deals with each separate software function and the 
organization of those functions [Ref. 7:p. 37]. With the 
exception of the Link Access Radio Group (LARG) , which 
consists of both hardware and software, the following segments 
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will comprise the CSS software. Figure 5 [Ref. 11] depicts 
how the software segments are linked. 

The Operating System/Inter-Process Communication 
(OS/IPC) segment provides the operating system functions and 
communication between segments [Ref. 7:p. 7]. 

The Subscriber Interface Control (SIC) segment is 
the interface between the subscriber (s) and the CSS 
resource (s). Components of the SIC will provide data 
transport reliability and accountability, and perform resource 
selection, flow control and status monitoring procedures for 
a specific subscriber. A Subscriber Data Unit (SDU) is the 
amount of information that the subscriber treats as a logical 
unit. The SIC will receive, buffer, process (for reliability 
and accountability) , and pass incoming SDUs from a resource to 
the subscriber; it will receive, process and route outgoing 
SDUs from the subscriber to the appropriate resource. If 
several resources have been assigned to a service, the SIC 
will continuously decide which resource to use for outgoing 
SDUs. Thus, if a resource were to malfunction, the SIC would 
send its SDUs to the other resource automatically with little, 
if any, disruption of communications. [Ref. 7:pp. 10-11] 

The SIC will also perform internet routing. It 
will receive SDUs from one resource and automatically reroute 
them to another resource in order to reach a destination. 
This capability will provide connectivity between platforms 
that do not share common resources. [Ref. 8] 
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Figure 5. CSS Functional Partitions 
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The Resource Access Control (RAC) segment is the 
interface between SICs and the resource. There will be one 
RAC per resource. The RAC will send incoming SDUs received 
from a radio subnetwork to the proper SIC. It will also 
receive SDUs from the SICs and determine the appropriate order 
of transmission over the subnet. The RAC will provide status 
information to the SIC, including expected waiting times (by 
service) and the current subnet connectivity, allowing the SIC 
to choose the best transmission resource among those resources 
defined in the CNCTNPLAN for its use. [Ref. 8] 

It is here where resource sharing is made possible. 
The RAC will maintain a transmit queue for each service. 
Selection of SDUs for transmission will be based on the 
service priority , data precedence and PAR values according to 
the CNCTNPLAN in effect. (The PAR parameter signifies the 
default percentage of the resource's transmission capability 
allocated to each service supported by the resource.) [Ref. 

6 : p . 26] 

Each queue will be examined for service priority. 
The SDU with the highest service priority will always be 
selected for transmission. If several queues have equal 
priority, the algorithm for transmission selection in the RAC 
will determine the next SDU to be transmitted. The 
determination will result in either of two cases, depending on 
whether data precedence processing is being used: 
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• Data precedence processing enabled. When several queues 
have equal priority, the SDU with the highest precedence 
will be selected for transmission. If several queues have 
the same precedence, the highest priority/highest 
precedence SDU from the service which has not yet exceeded 
PAR will be selected. If neither queue has exceeded PAR, 
the oldest SDU with highest priority and precedence will 
be selected. 

• Data precedence processing not enabled. When several 
queues have equal priority, the SDU from the service which 
has not yet exceeded PAR will be selected. If neither 
queue has exceeded PAR, the oldest SDU with highest 
priority SDU will be selected. [Ref. 6:pp. 25-27] 



Figure 6 [Ref. 3] further illustrates resource sharing and 
multimedia access. 

The Subnet Access Control (SAC) segment will 
exchange incoming/ outgoing SDUs with the RAC, and will provide 
the transmission access control for a radio subnetwork [Ref. 
9]. It will also provide other subnet management functions 
such as subnet activation and deactivation, and member entry 
and exit control [Ref. 8]. It will furnish to the operator 
the SAC's status, subnetwork's status, status of each network 
member, and the estimated delivery time to each member [Ref. 
6 :p. 25] . 

The Link Access Radio Group (LARG) is a combination 
of both hardware and software that provides link level 
encryption; modulation/demodulation; encoding/decoding; 
multiplexing; the radio; and antenna [Ref. 6:p. 33]. The SAC 
and the LARG, along with the transmission medium, constitute 
a CSS resource. 
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The System/Site Control (SSC) segment will be 
responsible for maintenance and dissemination of systemwide 
communication information and will enable a communications 
planner to match resources to services [Ref. 7:p. 12]. It 

will monitor the CSS hardware and software status and, with 
operator assistance, control the CSS hardware and software 
configurations whereby a new CNCTNPLAN may be designated [Ref. 

6 :p . 11]. 

The 
Operator Interface 
Control (OIC) 
segment will 
provide a display 
window using a 
standard X-Windows 
server and a 
keyboard/trackball 
operator input 
device [Ref. 8]. The OIC will accept commands from the 
operator, and will support the operator functions described in 
the next section. [Ref. 7:p. 12] 

Finally, the File Server /Control (FSC) segment will 
provide storage and retrieval of information when required by 
other segments [Ref. 7:pp. 7-8]. 




Figure 6. CSS Resource Sharing (top) and 
Multimedia Access (bottom) 
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c. The Standard Communications Environment 
Communication Services (SCE CS) and the SCE 

Standard Operating Environment (SCE SOE) 

The SCE CS includes the SSC, subscriber level 
security, the SIC and the RAC. The remaining software 
segments make up the SCE Standard Operating Environment (SCE 
SOE): the OIC, the OS/IPC and the FSC. Figure 5 [Ref. 11] 
demarcates the SCE and SOE areas. 

The CSS Standard Communications Environment 
Communication Services (SCE CS) has standard external 

interfaces (to the subscriber and SAC) and standard internal 
interfaces. In order for new radio subnets to function with 
CSS, their design must conform to SCE interface 
specifications. In this manner, new subnets may be added to, 
and be interoperable with, the SCE by connecting a new 
subnet's SAC and subscriber to a CSS RAC and SIC 

(respectively) via the standard SCE interface. [Ref. 8] 

4. CSS Operator Functions 

The OIC is designed as the interface between the 
operator and the CSS. On one platform, many operators could 
have access to the CSS, depending on the number of CSS 

workstations located on it (e..g., radio room operator, battle 
group communications planner). [Ref. 7:p. 28] 

Since all operators will not be required nor need to 
know how to perform all CSS functions, operators will be 
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assigned different levels of access to CSS based on their 
duties and responsibilities. At each CSS site, the SOE will 
contain an access list with the name of each user, level of 
access, and password which will allow him/her access up to 
that level within the system. A person designated as the 
site's CSS system administrator would manage and maintain 
control over access to CSS. [Ref. 7:p. 28] 

Automated network monitoring and management 
capabilities are provided by the CSS to assist operators in 
monitoring and controlling the real-time allocation of 
communications resources [Ref. 3], The OIC will interface 
with the operator via the X-Windows display in the form of 
user friendly menus on the terminal's color monitor screens. 
The menus implemented will conform to the User Interface 
Specifications for Navy C? Systems [Ref. 12], which will 
standardize menu presentation for Human Machine Interface 
(HMI ) users of both afloat and ashore FASTTs. The operator 
will simply select the option (s) he/she desires from the 
functions offered by the menu. As mentioned earlier, not all 
operators will have access to each feature. The main menu of 
the CSS console will provide the operator having authorized 
access and the proper permission level with the following 
options: 

• CONNECTION PLAN . The main features offered here will 
allow the operator to select a CNCTNPLAN by file name from 
the platform's data base, view it, edit it, activate it if 
desired, or, if necessary, delete it from the data base. 
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• MONITOR . This feature will furnish the operator with the 

status of the system: inactive segment (s) will be 

identified; the current EMCON level and conditions will be 
indicated; a list of subscribers at the site and their 
locations may be given; access will be provided to SIC 
segments assigned to each subscriber; available and active 
resources will be identified and their current status will 
be indicated; test messages may also be run here in order 
to locate system errors. 

• MAIL . This function is similar to electronic mail (E- 
mail) , and will allow informal coordination among 
terminals located on a TCC, or with other CSS platforms. 
This feature will be very helpful to platforms for 
coordinating the initial CNCTNPLAN configuration and when 
subsequent reconfigurations are required. 

• REPORTS . This attribute will provide its information to 

the operator in either graph or textual form. Information 
will consist of performance statistics: the current 

transmission status, the number of SDUs submitted, the 
transmission rate, and the average queue time. 
Additionally, a day file, or journal, will automatically 
log the commands performed by an operator in a 24-hour 
period. 

• SYSTEM MANAGEMENT . This particular function will be 

available only to authorized personnel with the 
appropriate password. Capabilities residing here are: 
Configure Hardware, to provide CSS the site's current 
hardware configuration; Configure Site, to provide CSS 
the site's current software configuration: Network 

Management, to review current workstations, add/ remove 
workstations, run LAN diagnostics, check network status; 
Operator Access, to list operators, access levels, 
passwords; Backup System, to create a backup for the data 
base; Recover System to restore a site's data base from a 
backup; Update Software , to load new software when 
upgrading a software segment; Restart System, to resolve, 
for instance, timing problems (this option will be 
selected in extreme circumstances only, since this would 
result in halting all site communications) ; Shutdown 
System, to terminate all CSS operations on a platform 
(usually during maintenance/long inport periods) . 

• UTILITIES . Capabilities offered for the operator's 
personal use will be a calculator, scratch pad, a logout 
option, selection of display attributes, and the ability 
to change the password of his/her own account. 
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• APPLICATIONS . This section will allow the operator to 
enter a TADIXS network from the CSS operator's console, 
converting it to a service workstation. [Ref. 7:pp. 28-35] 

Operators will be alerted to any resource losses or equipment 
malfunctions, and will be advised when action is required to 
resolve the problem [Ref. 6:p. 14]. 

C. CSS CONTRIBUTIONS TO C 2 

Service-to-resource matching to support the TADIXS 
networks will become more enhanced as CSS progresses toward 
complete implementation, incorporating the entire range of 
TADIXS bearer services (transmission media) envisioned: HF, 
VHF, UHF Line-of -Sight (LOS) , and all SATCOM. 

UHF, SHF and HF are said to be the frequency spectra that 
have the greatest potential for near term contribution to 
Copernican communications [Ref. l:p. B-3]. EHF SATCOM, 
however, is important because of its jam resistance. EHF 
SATCOM is also the first Copernican TADIXS bearer service that 
will be accessible through the CSS. This will be made 
possible by the NECC. 

Because of the extensive usage of UHF SATCOM systems and 
the Navy's investment of both time and dollars in the 
development of current UHF SATCOM systems, it is hoped that 
these systems will be made CSS-compatible as soon as possible. 
Efficient UHF SATCOM TADIXS services are envisioned by the 
author as capable of both UHF Demand Assigned Multiple Access 
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(DAMA) and CSS operations. The advent of the Tactical 
Intelligence Subsystem (TACINTEL) II Plus (shortly after NECC) 
should be the first step toward DAMA/CSS application, 
providing increased throughput and a multimedia capability to 
TACINTEL operations [Ref. 10]. 

1. The COPERNICUS Architecture 

Multimedia access and resource sharing will permit the 
evolution of TADIXS and TCC operations within the COPERNICUS 

architecture. They are the CSS features that will allow the 

. . . . 2 
tailored configuration of a tactical commander's C system 

discussed in Chapter II. 

Selection of communications services, TADIXS mix, and 
communications resources will be accomplished via activation 
by designated TCCs of a CSS CNCTNPLAN chosen by the tactical 
commander or SEWC (to whom this duty may be delegated) . The 
CNCTNPLAN itself will be based on the yet-to-be developed NWP 
matrices. The CSS will empower communications planners with 
the ability to prescribe service priority, data precedence 
(case) and PAR to the communications services which will 
support the mission. 

2. CSS Architectural Goals 

Now that the reader has been provided with a working 
knowledge of the system, the CSS Architectural goals will be 
discussed in further detail. 
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a. Increased Communications Flexibility and 

Survivability via Multimedia Access 
Increased communications flexibility and 

survivability via multimedia access will be accomplished 
without sacrificing user throughput or communications 
efficiency by allowing a TADIXS network to be restored on 
another resource (different radio) . Users will be able to 
maintain uninterrupted communications over several resources 
without operator intervention [Ref. 9]. This means that in 
the event of the loss of one resource, high priority services 
will automatically continue operating over their other 
assigned resources. 

As an example, a UHF SATCOM network can currently 
experience hours of degraded communications or total loss of 
communications because its assigned channel is experiencing 
interference or jamming, and because there is no other 
available channel on which to restore the network. However, 
once CSS is fully implemented, if a UHF SATCOM channel were to 
be jammed, multimedia access would allow the TADIXS networks 
supported on that channel to continue operating on another UHF 
SATCOM channel, or other media automatically. (Capabilities 
available at the IOC NECC will be discussed in Chapter IV.) 
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b. Increased Responsiveness to Rapid Changes in 
Warfighting Information Transfer Requirements 
Additional flexibility through fleetwide 

reconfiguration may be achieved by the activation of a new 
CNCTNPLAN: different subscribers; a new TADIXS mix; 

reallocation of resources — using different, additional, or 
fewer resources; and different service priority, data 

precedence (case) and PAR values. If a battle group's mission 
were to change, the CWC or SEWC would coordinate the 
designation of a new CNCTNPLAN and its activation with the 
FLTCINC and CCC/SEW Center personnel. The contents of the new 
CNCTNPLAN would be readily available to all concerned, simply 
requiring retrieval from each data base. 

Similarly, additional flexibility through 

reconfiguration may be achieved when authorized personnel make 
changes at a more localized level. For instance, the units in 
a Marine Amphibious Readiness Group (MARG) may collectively 
need to change ship/ shore frequencies to enhance operations. 
In both instances, CSS will significantly decrease planning, 
configuration, and network activation time, thereby increasing 
communications' responsiveness to a battle group's information 
transfer requirements. 
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c. Means for Incorporating New Communications 

Capabilities 

Incorporating new communications capabilities 
without requiring changes to the users 's baseband equipment or 
operating procedures will be accomplished by the CSS SCE 
specifications. As mentioned earlier, new systems will 
connect into the CSS with their SACs, SICs and subscribers 
designed to SCE CS specifications. This method of adding new, 
interoperable systems to the CSS should also result in minimum 
impact upon funding profiles of existing and planned programs, 
and lower future communications system development and life 
cycle support costs [Ref. 5:p. 2-2]. 

d. Maximized Use of Existing Communication Equipment 

With the full, or even partial, implementation of 

CSS, use of existing shipboard communication equipment and 
assets should be maximized by faster, more efficient 
throughput of digital data. Communications equipment 
(resources/radios) currently dedicated for one purpose (e.g., 
CUDIXS, OTCIXS) will no longer sit idle during periods of 
nontransmission. Other CSS services could use resources 
during those periods. 

Assets such as UHF SATCOM channels should 
ultimately be capable of supporting various TADIXS nets, 
instead of one channel being limited to supporting one network 
(e.g., CUDIXS) as is done today. Whereas today's operational 
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requirements vie for scarce UHF SATCOM channels, it is not 
unreasonable to say that many valid requirements presently 
unsatisfied may be accommodated in the future under their 
respective TADIXS categories. 

e. Simplified Communication System Operation and 
Maintenance 

As pointed out in the Operator Functions section in 
this chapter, CSS will facilitate operation and management of 
TCC communications assets. CSS plans to provide a useful flow 
of information to SEWC staff personnel and, in turn, allow 
transmission of concise direction to TCC platforms from the 
SEWC staff personnel. It is also the intention of CSS to 
identify system problems and advise operators of corrective 
actions early so that CSS Mean Time to Repair (MTTR) will be 
considerably enhanced. [Ref. 5:pp. 4-2 - 4-3] 

D. SUMMARY 

. . 2 
CSS is not only a system, but an architecture with C 

enhancement goals similar to those of COPERNICUS: increased 

communications flexibility, survivability, efficiency, 

reliability, increased responsiveness of communications 

systems, and maximized use of existing communication 

equipment. Multimedia access and resource sharing are the 

means by which CSS can achieve these goals. 

An open system architecture will facilitate addition of 

new systems to interface with CSS. Systems designed to SCE CS 
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design specifications may be added to the CSS, thereby 
permitting use of CSS resources. 
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IV. THE NAVY EHF COMMUNICATIONS CONTROLLER (NECC) 



A. EHF COMMUNICATIONS TODAY 

EHF communications came to be developed under the Military 
Strategic and Tactical Relay System, Milstar, a joint program 
designed to provide survivable, antijam, interoperable EHF 
satellite communications among the services [Ref. 13:pp. 49- 
51]. The recent conclusion of the Cold War has led to a 
reevaluation of Milstar. Whereas the majority of Milstar' s 
circuits previously were planned to support strategic 
requirements, a more tactical emphasis has now been placed on 
the system. Tactical users now stand a chance of greater 
system usage. 

In addition to the Milstar satellites, the Navy also has 
Fleet EHF Packages (FEPs) on FLTSATCOM (FSC) satellites 7 and 
8 and UHF Follow On (UFO) satellites 4 through 9 [Ref. l:p. 4- 
25]. The Navy EHF Satellite Program (NESP) terminals (AN/USC- 
38) , are planned to be installed on designated ships, 
submarines and shore sites, with an IOC in FY93. 

Because of its original objective, Milstar stressed 
survivability over capacity: throughput was intentionally 
sacrificed in order to ensure protection from physical attack, 
low probability of interception, secure encryption, and very 
high resistance to jamming [Ref. 13:pp. 51-53]. Consequently, 
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present EHF SATCOM programs support only low data rate (LDR) 
circuit operations (up to 2.4 kbps) [Ref. l:p. 8A-12]. 

The Space and Naval Warfare Systems Command, 
COMSPAWARSYSCOM, is currently designing a medium data rate 
(MDR) capability (up to 1.544 Mbps) which, once developed, may 
support the Copernican GLOBIXS [Ref. l:p. 8A-12]. This 
capability, however, will not be available at IOC; only EHF 
LDR communications will be supported at that time. 

B. THE NAVY EHF COMMUNICATIONS CONTROLLER (NECC) 

Under CSS, the Navy EHF Communications Controller (NECC) 
will provide the bearer service, EHFIXS , to NESP terminal 
platforms. The NECC will be installed with selected NESP 
terminals on both afloat (TCCs) and shore sites (NCTAMS, 
CCCs) . Due to funding limitations, not all NESP terminal 
installations will be accompanied by NECC installations 
initially. 

It is anticipated that six LANTFLT ships and one LANT 
shore site will receive NESP/NECC installations first [Ref. 
13]. This number should be sufficient for initial TCC/shore 
site communications, creating an interim operational period 
during which new uses can be ascertained, problems resolved, 
and procedures developed. If wisely used, this interim period 
can facilitate the transition to fleetwide NECC operations. 
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1. System Description 

In order to differentiate between the increments of 
the CSS architecture (of which the NECC is a project, or 
increment) and the incremental capabilities of the projects 
themselves, the systems' designers refer to project increments 
as builds [Ref. 14 :p. 1], For example, NECC Build One will be 
available for use in FY94 [Ref. 10]. Since the purpose of 
this thesis is to discuss operations at NECC IOC, the 
remainder of this chapter will address only NECC Build One. 
The Appendix [Ref. 15:pp. 110-112] provides a list of all 
capabilities planned for NECC Builds One and Two. 

The NECC Build One user community will include 
Tactical Data Processors (TDPs) . (For clarification, TDP is 
the Joint Operational Tactical System (JOTS) application 
software used normally on a DTC-2 terminal. TDP also refers 
to the Tomahawk Weapons Control System (TWCS) and Mission 
Display System (MDS) . A terminal using TDP software is often 
referred to as a TDP.) The NECC will interface with EHF 
SATCOM equipment (a standard CSS resource) and UHF SATCOM 
equipment (a nonstandard CSS resource) , providing these bearer 
services to the users [Ref. 15:p. 1], 

UHF SATCOM will not be considered a NECC resource in 
the CSS sense [Ref. 15:p. 14]. In order for a TDP to maintain 
backward compatibility with current OTCIXS and TADIXS A 
operations, an interface will be installed to permit continued 
communications over the UHF SATCOM OTCIXS and/or TADIXS A 
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networks by the NECC-TDP subscribers [Ref. 15:p. 28]. (UHF 
TADIXS A is not to be confused with Copernican TADIXS.) 

NECC Build One will be responsible for the following 
segments, some of which were described in the previous 
chapter: 



• The Hardware Segment, or Communications Controller (CC) ; 

• The CSS Standard Communication Environment (SCE) , which 
will provide configuration and monitoring, data transport, 
multimedia selection and access, and resource sharing. 
The SCE will consist of the System Site Control (SSC) , 
subscriber level security, the Subscriber Interface 
Control (SIC) , and the Resource Access Control (RAC) ; 

• The CSS Standard Operating Environment (SOE) , which will 
provide the operator interface, real-time multiprocess and 
multiuser operating system, and communications between 
processes (software segments) . The SOE will be comprised 
of the Operator Interface Control (OIC) , the Operating 
System/Inter- Process Control (OS/IPC) , and the File 
Server/Control (FSC) ; 

• The Connection Plan Generator/Security Manager (CPG/SM) ; 

• The EHF Subnet Access Controller (SAC) ; 

• The EHF Manager; 

• The TDP Subscriber; and 

• The Advanced Narrowband Digital Voice Terminal (AN DVT) 

SAC. [Ref. 15 : pp . 24-25] 



Discussions on each segment not described earlier follow. 
Figure 7 [Ref. 14 :p. 3] is a proposed block diagram of the 
NECC at Build One. (The Navigation Data Source in the figure 
will be located in the NECC data base and will provide a 
site's position to other sites in support of EHF transmissions 
[Ref. 17].) 
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Figure 7 . Conceptual NECC Build One 



The Connection Plan Generator/Security Manager 
(CPG/SM) will provide operators the ability to generate and 
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tailor a connection plan (CNCTNPLAN) , and to transfer the 
connection plan to other sites [Ref. 15:p. 36]. Different 
levels of these capabilities will be made available to CSS 
operators, depending on their Copernican function: the theater 
planning site (such as the CCC) , the CWC's (or numbered fleet 
commander's) site, or simply an operational site (TCC) . The 
reader will become familiarized with CNCTNPLANs in the next 
chapter. 

At the planning site, theater and site CNCTNPLANs will 
be generated, received, stored and distributed; NECC software 
will be received from a software maintenance activity, stored, 
distributed and managed; and key requests may be generated. 
At the site of the battle group commander, CNCTNPLANs will be 
received, stored, edited and distributed, and NECC software 
may be received and stored. Operational sites will receive 
and store both site CNCTNPLANs and NECC software. Controlled 
access to the NECC data base for CNCTNPLAN generation and 
software distribution management will exist at all sites. 
[Ref. 15 : p . 36] 

The EHF Subnet Access Controller (SAC) will perform 
the SAC functions described in Chapter III by allowing an 
operator to manage the EHFIXS subnetwork. The EHF SAC will 
also interface with the CSS SCE so that the SCE may access the 
transmit and receive capabilities of the EHF SATCOM circuits. 
[Ref. 1 5 : pp . 24, 32] 
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The EHF Manager will assist the NECC operator in the 
planning and management of EHF circuits [Ref. 15:p. 25]. It 
will allow the operator to plan EHF circuit configurations and 
evaluate how those configurations fit within the constraint of 
available NESP terminal resources and satellite assets. It 
will keep track of resources and assets used by EHF services 
and will attempt to fit additional requirements into the 
remaining resources and assets. If availability or coverage 
problems exist, alternate configurations will be presented. 
If there are no feasible alternatives, the operator will be 
notified. [Ref. 16:pp. 13-14] 

The EHF Manager will present information to the 
operator regarding EHF subnet configurations based on EHF 
satellite coverage, capacity requirements, available payload, 
and NESP terminal resources. NESP terminal configuration 
information, based on the EHF circuit requirements entered and 
existing terminal resource constraints, will also be 
displayed. [Ref. 15:p. 38] 

The Tactical Data Processor (TDP) Subscriber will 
provide an interface between TDP terminals and the NECC via 
the CSS Communications Controller (CC) without the need for 
any modification to the TDP terminal itself. It will maintain 
backward compatibility with the UHF SATCOM resources that the 
TDPs use, offering three options for transmission of NECC-TDP 
information: the user will be able to send his/her information 
via UHF SATCOM, EHFIXS, or over both media. At TADIXS gateway 



53 



shore sites, the routing decision will be made at the TADIXS 
Gateway Processor . EHF communications via the NECC-TDP 
Subscriber will be similar to those currently used by TDPs for 
UHF OTCIXS/TADIXS A network communications. [Ref. 15:pp. 
24,28] 

The Advanced Narrowband Digital Voice Terminal (ANDVT) 
SAC is intended to permit shared voice and data usage of a 
resource formed by the ANDVT and EHF service. The ANDVT SAC 
is not funded at this time. NECC Build One will not include 
an EHF SATCOM voice capability. However, EHF ANDVT 
communications will be possible among NESP terminal users 
without the use of NECC. Once funded and installed, the ANDVT 
SAC could provide a secure voice capability among NECC users. 
[Ref. 15 : pp. 33-34] 

2. Other Capabilities 

As would be expected, the NECC will provide EHF 
multimedia access and resource sharing. NECC resource sharing 
will include the CSS algorithm defined by the current SCE 
specifications. Thus, use of EHF resources will be based on 
the service priority, data precedence and PAR assignments 
designated by the SEWC staff in the CNCTNPLAN. 

NECC Build One will also provide many of the CSS 
operator functions described earlier in Chapter III: 
accountable data transport service, embedded training; on-line 
documentation; alerts; help; subscriber level security; day 
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file journal; CNCTNPLAN retrieval and conversion to a site 
configuration; site configuration edit and activation; site 
configuration display; automatic software-to-hardware 
assignment; EHF SATCOM subnet selection; EHF SATCOM subnet 
access sharing; operating system support for the NECC 
segments; operator interface support; file services; and data 
base services [Ref. 15:pp. 29-31]. 

The Embedded COMSEC Adapter (ECA ) , or External KG-84 
Adapter, will provide subscriber level encryption. It will be 
used within the NECC to separate the NECC subscriber and the 
SCE, and will provide a trusted bypass for control information 
transfer between the subscriber and the SCE [Ref. 15:p. 44]. 

Figures 8 and 9 [Ref. 14:pp. 26-27] illustrate 
proposed shore TADIXS gateway and shipboard site 
configurations. Both configurations show the TDP subscriber 
linking the CSS SCE, the TDP terminals and the UHF resources 
(the ON-143, UHF SATCOM interconnecting group and the TD-1271, 
UHF DAMA multiplexer) . AN DVT SACs are included in both 
figures. The shore gateway configuration includes the TADIXS 
Gateway Processor. In the shipboard configuration, TWCS and 
JOTS TDPs are depicted. 

C. NECC APPLICATIONS 

Until a wider range of services can be fully integrated 
into the CSS (other SATCOM, UHF LOS) and the NECC (voice, 
TTY) , and before an EHF MDR capability is developed, the CSS 
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Figure 8. Conceptual Shore Gateway Site Configuration 
(NCTAMS) 



will not function as discussed in the previous chapter. 
Initial NECC operations will provide multimedia access and 
resource sharing among EHF services and resources only. It is 
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Figure 9. Conceptual Shipboard Site Configuration 



imperative that both UHF and SHF SATCOM, as well as other 
bearer services, be made standard CSS resources as quickly as 
possible in order to provide increased communications 
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. . . . 2 

survivability and flexibility m support of C . The ANDVT 
SAC, which could provide NECC a voice capability, is not 
funded at this time. If it is not feasible to incorporate 
ANDVT voice communications into NECC, it must be incorporated 
into CSS via some other CSS resource, 
l. Near Term Applications 

In the near term, however, NECC will provide 
considerable enhancements to operations and communications 
management. NECC will, in effect, offer the prototype Force 
Operations TADIXS, intended to support Strike Warfare, ASW, 
AAW and ASUW. TADIXS A broadcasts critical Over-the-Horizon 
Targeting (OTH-T) information to tactical units in support of 
Strike Warfare, Anti-Surface Warfare (ASUW) and Anti-Air 
Warfare (AAW) missions. OTCIXS supports acknowledgment of 
receipt of mission-critical TADIXS A information and ship-to- 
ship/ship-to-shore OTH-T transmissions. A separate OTCIXS 
link enables Submarine Operating Authorities (SUBOPAUTHs) to 
transmit OTH-T information to submarines, and enables the 
transmission of oceanographic and meteorological information 
as well. Both networks support NTCS communications and permit 
communications between NTCS users and other TDPs, such as 
those used by the Tomahawk Weapons Control System (TWCS) . 
[Ref. 15 :pp. 85-94] 

The addition of an EHF capability to the TADIXS A and 
OTCIXS networks will improve C 2 . EHF will afford these 
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networks a higher degree of resistance to jamming and OTH-T 
communications outages. 

The additional EHF OTCIXS and TADIXS A will also 
provide those UHF networks some redundancy. The resultant 
flexibility might relieve some of the dilemmas that 
periodically face communications managers and users today. 
There are three areas where this flexibility might prove 
useful : 

• Restoral of UHF networks using EHF; 

• Reduction of traffic loading on UHF networks; and 

• Support of no-notice UHF requirements. 

a. EHF Restoral of UHF Networks 

Should either the UHF OTCIXS or TADIXS A suffer 
outage or degradation due to intentional jamming or 
unintentional interference, NECC user network operations could 
continue on EHFIXS. Partial EHF restoral by only those 
platforms with NECC would ensure that key players continued to 
transmit and/or receive vital information. This information 
could then be passed to non-NECC platforms via other means 
(e.g., voice, orderwire) . If UHF communications were lost 
aboard a NECC-equipped ship, EHF OTCIXS and TADIXS A 
communications would continue. 

Shore stations would benefit as well during UHF 
satellite or some UHF equipment outages. A TADIXS A keying 
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station could still transmit EHF TADIXS A if it were NECC- 
equipped; a NECC-capable TADIXS gateway could continue 
operations over EHF SATCOM. 

b. Reduction of OHF Network Traffic Loading 

EHFIXS could be used to reduce loading during heavy 
UHF OTCIXS traffic periods. NECC subscribers could use the 
EHF network to receive and transmit their messages, thus 
lightening the load on the UHF channel and allowing more rapid 
delivery of message traffic. 

c. Support of No-notice UHF Requirements 

Emergency activations of UHF circuits could be 

supported. For instance, a UHF DAMA slot could support a 
sudden high priority requirement if NECC UHF TADIXS A and/or 
OTCIXS users temporarily shifted to EHFIXS operations. Such 
operations would continue until the UHF DAMA slot were 
released back for its original use. Although this procedure 
would result in restoral for NECC users only, it might save a 
network from total preemption by the higher priority 
requirement. This capability could also be used to support 
lesser priority theater requirements, such as exercises, at 
the discretion of the FLTCINC. 

As shown above, even partial execution of these 
restoral methods by NECC-equipped platforms would contribute 
a greater flexibility to fleetwide communications. Often, a 
small amount of flexibility is all that is required to resolve 
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SATCOM emergencies and short-fused requirements. As 

additional systems are incorporated into CSS and NECC, 
communications flexibility can only increase. 

2. Future Applications 

Some possible applications for NECC in the future 

include: expanded Strike Warfare communications support, for 

example, the transmission of Tomahawk mission planning 

material (MPM) via Mission Data Updates (MDUs) to Afloat 

Planning Systems (APS) aboard carriers; intelligence and 

imagery support; communications services between AAW and ASUW 

subscribers; and Surveillance Direction System (SDS) 

communications in support of ASW. [Ref. 15:pp. 85-93] 

EHF SATCOM continues to be the most jam-resistant of 

all satellite communications. In order to maximize use of the 

Navy EHF communications system and CSS, and to provide optimal 
. . 4 

capability to Navy Cl, MDR EHF design and development must 

continue to completion and be incorporated into the NESP 

terminal to operate with NECC for future use of satellite MDR 
capability once it becomes available on Milstar. 

D. SUMMARY 

Due to the previous emphasis on survivability, the NESP 
terminal (IOC 1993) will initially support circuits of up to 
2.4 kbps. A MDR capability is being developed by 

COMSPAWARSYSCOM . 
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The NECC will be the first communications system to 
operate under CSS and, in conjunction with the NESP terminal, 
will bring EHFIXS to NECC-capable Tactical Data Processor 
(TDP) sites. At NECC IOC (1994), additional communications 
flexibility will be provided in support UHF network restoral, 
UHF network traffic loading, no-notice UHF requirements. In 
order to enhance jam-resistant EHF SATCOM, MDR development 
should continue to completion. 
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V. CSS/NECC PLANNING AND MANAGEMENT AT IOC 



A. INTRODUCTION 

The Naval Ocean Systems Center (NOSC) [Ref. 7] provides an 
approach to CSS communications planning. The first planning 
stages in the development of an individual CSS site's 
connection plan (CNCTNPLAN) , based on a FLTCINC communications 
plan (COMMPLAN) , will be discussed here. The discussion is 
based on the approach, using the services and resources 
provided by NECC together with the NESP terminal at IOC. 

Many possibilities exist in the development of a 
CNCTNPLAN: parameters such as service priorities and PARs may 
vary from theater to theater, from operation to operation, 
from one platform to another, or even from one time period to 
another. A simple case will be discussed here in order to 
point out how the parameters might be used to define a 
CNCTNPLAN. Managerial issues will be discussed as they arise, 
and any difficulties encountered in the process will be 
identified. Recommendations are proposed throughout the 
procedure. It is hoped that the reader will better understand 
these parameters for planning purposes, and that he/she will 
gain an appreciation for the configuration possibilities that 
both CSS and NECC offer. 



63 



B. CBS COMMUNICATIONS PLANNING APPROACH 

As mentioned earlier, CNCTNPLANs will be based on matrices 
of a future NWP, and those matrices will be derived from 
existing Joint Doctrine, theater OPLANs, and COMMPLANs within 
a FLTCINC's Area of Responsibility (AOR) . It is anticipated 
that the development of a CNCTNPLAN for a TCC will be a top- 
down procedure, starting at the FLTCINC level with general 
guidance provided in the form of CSS COMMPLAN requirements, 
then working down to the numbered fleet and battle group 
commanders. Lower command levels will review the COMMPLAN 
information upon receipt for feasibility and add more detailed 
information, such as frequencies and smaller networks or 
network members. The completed COMMPLAN will then be sent to 
individual ships for implementation. Figure 10 [Ref. 7:p. 20] 
illustrates proposed planning functions at the various command 
levels. [Ref. 7:pp. 20-21] 

It is intended that information be entered into the CSS 
COMMPLAN at the highest level that information is known [Ref. 
7:p. 21]. For example, the numbered fleet commander or battle 
group commander might designate a UHF line-of-sight (LOS) or 
HF service to support carrier flight operations and assign to 
it frequencies obtained from the NCTAMS . 

It is recommended that close coordination with the Naval 
Computer and Telecommunications Area Master Station (NCTAMS, 
formerly NAVCAMS) be conducted by all command levels in order 
to confirm CSS COMMPLAN feasibility and to determine if there 
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are any requirements for 
shore site involvement. 

The participation of the 
NCTAMS in the planning 
process within its 
COMMAREA is highly 
valuable because it 
often provides much 
insight and assistance 
to commanders both 
ashore and afloat. 

It is intended that 
the first planning step 
in the development of a 
CSS COMMPLAN will 
include the following 
procedures: 

• set up services , by matching specific operational 
requirements defined by the FLTCINC to appropriate 
services in order that each resource requirement be 
defined ; 

• set up resources , by identifying available resources based 
on the operational characteristics of each specific 
service identified in the previous step; 

• match services to resources ; then 

• promulgate the information to the numbered fleet 
commanders. [Ref. 7:p. 20] 
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Each of these steps will now be discussed in more detail. 
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l. Setting Op Services 

CSS services will be defined according to the service 
type. The type for a specific service will consist of its 
particular characteristics: 



• data type , the type of information sent over the service, 
may be in message, digital voice, tactical data, imagery, 
or file form; 

• delivery time, the case of the information, and how 

quickly it must arrive at its destination (s) : Case 1 

(three minutes or less, Case 2 (15 minutes or less) , or 
Case 3 (three hours or less) [Ref. l:pp. 3-9 - 3-12]; 

• delivery features , the information may be sent via point- 
to-point, multicast (to two or more sites, either 
addressed to them individually or via a collective 
address) , or broadcast, and may be accountable or 
nonaccountable [Ref. 17]; 

• security requirements, the information may be SI or 
GENSER, and will require a specific type of crypto 
equipment and keying material (keymat) ; 

• subscriber type, the information may be sent or received 
via TDP, TTY, or FASTT subscribers [Ref. 7:p. 5]; 

• service membership , the CSS and non-CSS platforms who will 
be communicating within a service; and 

• theater service priority , the recognized priority of a 
service within a specific COMMAREA. [Ref. 17] 



Several of these characteristics require further discussion, 
a. Accountable and Nonaccountable Delivery 

Accountable delivery occurs when the sender is 
notified that the information was received. In the case of 
nonaccountable delivery, no notification will be received. 
Nonaccountable delivery might be used for reports that are 



66 



updated frequently, and consequently often superseded. [Ref. 
17] 

b. Service Membership 

It is important that any services that consist of 
both CSS and non-CSS users be identified at this step in order 
to simplify the subsequent steps where resources will be 
identified and assigned to support services. This is because 
CSS users will need to dedicate a resource to establish and 
maintain communications with non-CSS users. It may even be 
desirable to have two similar services designated in this 
situation: one to support CSS communications among CSS users, 
and one for non-CSS communications. This configuration would 
be comparable to the dual UHF/EHF OTCIXS/TADIXS A operations 
that will exist at IOC. [Ref. 7:p. 21] 

Although not required at this point, some or all 
desired network participants may be specified [Ref. 7:p. 21]. 
As previously discussed, HF or UHF LOS services such as those 
which support MARG or carrier operations may be added, along 
with specified members, to a COMMPLAN at lower command levels. 

c. Theater Service Priority 

Note that theater service priority is used on an 
areawide basis. Because the CSS algorithm permits each site 
to assign service priorities individually, a battle group's 
service priorities may somewhat differ from theater service 
priorities, and a platform's CNCTNPLAN service priorities can 
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differ from those of both the FLTCINC and the battle group 
commander. The absolute priority of a service within a 
specific site's CNCTNPLAN may be referred to as the service 
contingency value [Ref. 18:p. 24). For instance, a ship 
receiving special support via point-to-point communications 
with a Naval Computer and Telecommunications Station (NCTS) 
would give that service a very high contingency value, where 
it would not even be listed in another ship's CNCTNPLAN. 
Thus, CSS and NECC will permit the CCC, CWC or SEWC, and TCCs 
to designate theater, battle group and ship service priorities 
respectively. In this chapter, the term service priority will 
be used to mean service contingency value unless otherwise 
specified . 

It is recommended that the CSS COMMPLAN contain the 
theater service priority, but that the CWC, SEWC and TCCs 
assign to CSS services priorities appropriate for their 
missions and special requirements. Service priorities within 
a battle group or for particular CSS platforms could be 
assigned and controlled by the SEWC or the SEW Center 
personnel. For example, if a TCC had to change service 
priorities significantly due to a change in mission or in 
order to improve its flow of outgoing traffic, it could report 
the change to the SEWC or SEW Center personnel (either via 
voice or data) , and report once again when the services 
reverted to the original assignment. 
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Should guidance be required to prioritize services 
within theater, the latest UHF SATCOM Prioritization Plan, 
developed by the FLTCINCs and promulgated by CNO, might be of 
some assistance. The plan lists types of UHF SATCOM networks 
in order of precedence and serves as guidance for 
communications planners when emergency preemption of a network 
is required. Its priorities range from 1 (highest) through 5 
(lowest) . Increments within each priority provide further 
definition of precedence. A UHF network classification 
related to the CSS service in question could be identified in 
the plan, and its priority used as a basis for discussion 
among planners for prioritizing CSS services. 

2. Setting Up Services at IOC 

The CSS COMMPLAN being generated here is in support of 
special operations where an EHF HICOM ANDVT service is 
required in addition to the exchange of EHF OTH-T information. 
At NECC IOC, EHF OTCIXS and TADIXS A networks will be 
available. In order to differentiate these networks from 
their UHF counterparts, EHF OTCIXS will now be referred to in 
this chapter as OTH-T COMMS; EHF TADIXS A will now be referred 
to as OTH-T BCST. Non-NECC EHF services supporting ANDVT 
voice and TTY communications will also be available [Ref. 17]. 

At IOC, NECC service characteristics may be defined in 
the following manner: 
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• data types will consist of operator-to-operator (OTO) 
messages and tactical data (in the form of OTCIXS message 
format) ; 

• delivery times over OTH-T services may still be designated 
by the precedences Flash (Z) , Immediate (0) , Priority (P) 
and Routine (R) , since message traffic may continue to be 
sent out over UHF SATCOM; 

• delivery features offered will be single- or multi- 
destination (including broadcast), and accountable or 
nonaccountable [Ref. 17]; 

• security requirements supported by NECC will be GENSER, 
encrypted by KG-84A crypto with the appropriate keymat; 

• subscriber type available will be the TDP Subscriber; 

• service membership will be include NECC and non-NECC 
platforms at IOC; and 

• theater service priorities may range from 1 through 5 (if 
the UHF SATCOM Prioritization plan is used) , or a larger 
range of priorities may be used. 



These characteristics will become more important as services 
start to shift toward Copernican TADIXS virtual networks and 
as CSS and NECC expand. In this example, several service 
characteristics will be used in the sample COMMPLAN and 
CNCTNPLAN at the end of the chapter. 

The CSS service list might be considered a worksheet 
that planners can use to develop communications requirements, 
or that an individual site can use in developing its 
CNCTNPLAN. TABLE 1 is an example of how a CSS COMMPLAN 
service list might look at IOC. All six units planned to have 
NECC (ships A through F) are designated as service 
subscribers. The CCC and a NCTS have been added as shore 
subscribers. Note that HICOM AN DVT consists of both NECC and 
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non-NECC users. Ships X, Y and Z have NESP terminals, but do 
not have NECC. 

Service numbers have been added so that they may be 
recognized by CSS and NECC. It is recommended that these 
numbers be standardized to avoid any confusion among CSS 
sites. It is also recommended that this standardization take 
place during the development of the Copernican NWP. 

Upon fuller implementation of CSS, the service list 
and COMMPLANs could become quite large. As COMMPLANs are 
developed, the corresponding CNCTNPLANs will be entered into 
each site's data base and updated regularly, perhaps via 
Communications Information Bulletins (CIBs) issued by the 
NCTAMS. Regular updating should facilitate working with both 
COMMPLANs and CNCTNPLANs as they expand. 



TABLE 1. SERVICE LIST 



SERVICE 


SERVICE NR 


SUBSCRIBERS 


OTH-T COMMS 


OCIOOO 


A, B, C, D, E, F, NCTS , CCC 


OTH-T BCST 


OBIOOO 


A, B, C, D, E, F, NCTS, CCC 


HI COM AN DVT 


HI1000 


A, B, C, D, E, F, X, Y, Z, 






CCC 



3. Setting Up Resources 

At this step, available resources will be identified. 
Available resources are resources, or percentages of 
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resources, not previously assigned to support services. 
Actual definitions of the characteristics (e.g., frequencies) 
of the resources will be provided by CSS and stored in its 
data base, so only identification of the resources themselves 
will be needed. Resource frequencies will be expressed in 
terms of frequency band, not in terms of any specific 
frequencies. For instance, the frequency band for OTH-T BCST 
will be expressed simply as EHF. [Ref. 7:p. 21] 

It is well noted that until the SEWC is established 
and SEW Center personnel duties become clearly defined, the 
FLTCINC will continue to be actively involved in all use of 
SATCOM for accountability purposes. Since this will probably 
be the case at IOC, an additional column should be added to 
the resource list specifying which SATCOM frequencies are to 
be used. Once Copernican TADIXS and doctrine become firmly 
established, however, this responsibility could be delegated 
to SEW Center personnel. 

CSS coordination and planning will continue to be as 
important as they are now. Planning requirements that cannot 
be met may be identified, reported and corrected at lower 
command levels, but it is essential that the CSS shore 
planning process be as comprehensive and accurate as possible. 
CSS planning tools should be designed to include mechanisms 
that will allow early identification of any deficiencies. In 
this manner, most problems can be resolved at the higher 
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command levels before promulgation to the fleet, precluding 
the need for emergency workarounds. 

4. Setting Up Resources at IOC 

NECC resources may be viewed at three distinct levels: 
EHF satellite capacity allocation to the FLTCINC (which may 
vary according to EHF satellite used, Milstar, FLTSATCOM, or 
UFO) ; the percentage of that capacity allotted to the battle 
group commander by the FLTCINC; and an individual platform's 
resources, dependent on the available satellite capacity [Ref. 
10]. For this reason, and because platforms will use their 
resources differently, coordination with the NCTAMS is once 
again stressed. 

Available NECC EHF resources at IOC will be 
restricted to those platforms that have both NESP terminals 
and NECC (one ashore, approximately six afloat) . NESP 
ship/shore terminals will contain twelve resources, or ports: 

• four primary transmit/receive (75-2400 bps) ; 

• four secondary transmit/ receive (75-300 bps) ; and 

• four receive only (75-300 bps) [Ref. 10]. 

The receive-only LDR ports might be used for receipt of 
broadcasts. Four of these ports will be designated for NECC 
use (which four ports is not known at this time) [Ref. 17]. 
For discussion purposes, it will be assumed that each NECC 
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platform will possess two primary transmit/receive and two 
receive-only NECC resources. 

A CSS resource list may also be considered a worksheet 
used by planners and TCCs in conjunction with the CSS service 
list when matching services to resources. TABLE 2 illustrates 
a sample COMMPLAN resource list at IOC. Identification 
numbers have been assigned to each resource so that CSS and 
NECC may differentiate among them. These numbers will also 
require standardization to avoid confusion at the next step 
when services are matched to resources. One suggestion would 
be to refer to a site's primary transmit/receive EHF resource 
as Resource EHF0001; the second primary transmit/receive EHF 
resource as Resource EHF0002, etc. In this manner, they can 
be differentiated from other resources (VHF, UHF SATCOM) added 
to CSS. 



TABLE 2. RESOURCE LIST 



RESOURCE NUMBER 


EHF RESOURCE 


0001 


TRANSMIT/RECEIVE 


0002 


TRANSMIT/RECEIVE 


0003 


RECEIVE 


1 , - 1 •* — — ■— - — ' ^ ' 

0004 


RECEIVE 
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5. Matching Services to Resources 

a. Assigning Service Priorities 

CSS service contingency value will depend on the 
site, or platform (CCC, TCC) , and its mission: networks which 
directly support mission operations will have a higher 
priority [Ref. 7:p. 23]. Since HICOM ANDVT is a voice service 
supporting the special operations, it should be given a high 
priority. 

Recall that service contingency values can vary 
from one platform to another. In this example, if a ship were 
not participating in the special operations, it would not be 
required to activate HICOM ANDVT, and HICOM ANDVT would not be 
in its CNCTNPLAN. 

b. Matching Services to Resources 

As discussed in Chapter III, multimedia access and 
resource sharing will provide CSS/NECC users four options: 

• one resource supporting one service 

• one resource supporting multiple services 

• multiple resources supporting one service 

• multiple resources supporting multiple services 

CSS should be of some assistance to both planners 
and individual platforms by providing an acceptable 
configuration that will satisfy requirements. The OIC is 
planned to provide tools and templates to help determine 
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reasonable service-to-resource matching [Ref. 7:p. 23]. The 
NECC CPG/SM will automatically track service and resource 
memberships, providing the operator this information in 
display or report form [Ref. 18:p. 32]. 

Communications with non-CSS ships will be 
identified first in order to designate dedicated resources 
[Ref. 7:p. 22]. After this has been accomplished, remaining 
resources may be assigned to the other services in order of 
descending priority. This will ensure that the highest 
priority service requirements will be satisfied first. 

c. Percentage Allocation of Resource (PAR) and Data 

Precedence Processing 

After services have been matched to resources, PAR 
will be assigned to each service to specify allocation of 
resources among services. Data precedence processing (where 
delivery times are specified according to case) may be enabled 
at this point to further define resource sharing. 

6. Matching Services to Resources at IOC 

Matching services to resources at IOC should be a 
fairly straightforward procedure since the NESP terminal will 
provide all users in the theater four NECC resources. EHF 
will be the only CSS frequency band, and NECC EHF services 
alone may be matched to NECC resources. 

At IOC, EHF communications will consist of two types 
of subscriber configurations: 
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• services among NECC users employing NESP terminal ports 
designated as NECC resources; or 

• networks among NECC user(s) and non-NECC NESP terminal 
user(s) employing a NESP terminal port [Ref. 17]. 

The second configuration will be necessary because, as 
mentioned earlier, NECC platforms will be unable to use NECC 
to communicate via EHF with non-NECC platforms. (NECC users 
will still, however, maintain UHF OTCIXS and TADIXS A 
communications with both non-NESP and non-NECC users.) 
Communications among NECC and non-NECC subscribers, such as 
HICOM ANDVT , will require a dedicated NESP terminal port, 
a. Assigning Service Priorities 

When assigning service contingency values, the 
highest service priority should be designated first, with the 
lower priority services specified accordingly. These will be 
based on theater service priorities, but may not exactly match 
them. For demonstration purposes, both OTH-T COMMS (EHF 
OTCIXS) and OTH-T BCST (EHF TADIXS A) will be assigned a 
service priority of 1, although they could have been given any 
priority deemed appropriate for the operation being conducted 
(or for a particular platform's needs), and do not need to 
have the same priority. In case emergency restoral of CSS 
services should be required, HICOM ANDVT is also given a 
priority. Since it directly supports voice communications 
among the FLTCINC, numbered fleet commander and BG commander, 
HICOM ANDVT is also given a priority of 1. 



77 



b. Matching Services to Resources 



Recall from Chapter III that for outgoing 
information , when data precedence processing is enabled and 
several queues have equal priority, the Subscriber Data Unit 
(SDU) with the highest precedence will be selected for 
transmission. If several queues have the same precedence, the 
highest priority/highest precedence SDU from the service which 
has not yet exceeded PAR will be selected. If neither queue 
has exceeded PAR, the oldest SDU with highest priority and 
precedence will be selected. 

Only Resources 0001 and 0002 have transmit 
capability, so only the services assigned to these resources 
will require data precedence processing and PAR values. 
Platforms that receive the OTH-T BCST will not need to 
designate these parameters. However, the CSS COMMPLAN should 
reflect as much information regarding receive-only services as 
possible in case emergency preemption of services were 
necessary. OTH-T BCST's service priority is included. 

Looking at the CSS resource list, OTH-T COMMS could 
be assigned to Resource 0001, a primary transmit/receive 
resource. Although OTH-T BCST requires only a receive-only 
resource, it must be assigned to a primary transmit/receive 
resource because its data rate is 2400 bps. A platform 
receiving OTH-T BCST could assign it to Resource 0002, using 
only the receive portion of that resource. (Note, however, 
that the shore station that uplinks OTH-T BCST would have to 
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designate a transmit/receive resource, using only the transmit 
portion of the resource.) 

The service-resource matrix in TABLE 3 reflects a 
configuration temporarily dedicating Resource 0001 to OTH-T 
COMMS and Resource 0002 to OTH-T BCST. (Other services could 
be assigned to either resource at a later time.) Resource 
0002 is assigned to OTH-T BCST, but is not dedicated because 
none of its transmission capability will be used to support 
OTH-T BCST. 

c. PAR and Data Precedence Processing 

It is important when assigning PAR to a service to 
remember that the number of resources available will depend on 
how the resources will be used. For instance, in TABLE 3, 
OTH-T COMMS is supported by Resource 0001. This resource 
supports no other services. Therefore, the PAR assigned to 
OTH-T COMMS may be 100, meaning that 100 percent of Resource 
0001* s transmission capability supports OTH-T COMMS. If, 
however, Resource 0001 were already assigned to a service or 
several services, a decision would have to be made on how that 
resource would be shared between/among the services. This 
decision could be made at a platform level (if an individual 
TCC's service were affected) or at the SEWC level (if a 

t 

service with many TCC subscribers were affected) , and would 
depend on the service priorities involved. 
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TABLE 3. SERVICE-RESOURCE MATRIX: DEDICATED RESOURCES 



SERVICE 


SVC NR 


EHF RESOURCES 




NUMBER 


PRIORITY 


PRECEDENCE 


PAR 


1 

OTH-T COMMS 


i 

OCIOOO 


0001 


1 


YES 


100 


OTH-T BCST 


OBIOOO 


0002 


1 


— 


0 



TABLE 3 also reflects that, since OTH-T BCST 
subscribers only receive information, precedence and PAR do 
not apply. The Precedence column is left blank. The PAR 
column contains a zero (0) . Theater service priority is 
retained for information purposes in case an emergency such as 
resource failure were to occur. 

PAR assignment will also depend on how much traffic 
travels over each circuit. Remember that PAR will only be 
used when SDUs awaiting transmission by the same resource have 
the same precedence (if enabled) and the same priority: when 
they are in contention for transmission. In these instances, 
the SDU from the service which has not yet exceeded PAR will 
be transmitted first. 

If a service has equal priority with another 
sharing the same resource, but has a higher volume of outgoing 
traffic, it should be assigned a higher PAR. In this manner, 
its SDUs can experience a higher percentage of resource usage 
before PAR is exceeded and they come into contention with 
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those of the other service. If the high volume service 
exceeds PAR, and the low volume service has not, its SDUs will 
start to get "bumped" by the other service's. Only until the 
low volume service exceeds PAR will the oldest SDU (presumably 
from the high volume service) be selected for transmission. 

Keeping this in mind, two transmitting services of 
equal priority sharing a resource may be assigned PAR 
combinations such as 45/55, 10/90, or 70/30 percent, 
indicating that they share 100 percent of that resource's 
transmission capability. They may also be assigned 
combinations such as 25/25, 60/20, or 40/10, indicating that 
50, 20, or 50 percent (respectively) of that resource's 
transmission capability is still available to support another 
service, or other services) . They will even be able to use 
that resource's available capacity when no other service is 
using it [Ref. 17]. 

In TABLE 4, OTH-T BCST and OTH-T COMMS share 
Resource 0001. Resource 0001 supports no other services. 
Since PAR applies to outgoing traffic only, OTH-T COMMS can 
still be assigned all (100 percent) of Resource 0001 's 
transmission capability. If required, additional services 
could share Resource 0001. Once again, OTH-T BCST ' s 
precedence column is left blank, and its PAR remains at zero 
( 0 ) . 

In TABLE 5, multimedia access is indicated: two 
resources have been assigned to OTH-T COMMS. In this case, 
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Resource 0001 does not support any other services and Resource 
0002 supports OTH-T BCST, so each resource's PAR of 100 
percent may be assigned to OTH-T COMMS . This method of 

resource allocation should ensure faster transmission of OTH-T 
COMMS information because its high precedence SDUs will have 
two resources over which they can be transmitted. Once again, 
OTH-T BCST's precedence column is left blank, and its PAR 
remains at zero (0) . 



TABLE 4. SERVICE-RESOURCE MATRIX: RESOURCE SHARING 



SERVICE 


SVC NR 


EHF RESOURCES 


_ 


NUMBER 


PRIORITY 


PRECEDENCE 


PAR 1 


1 * 1 

OTH-T COMMS 


i 

OCIOOO 


0001 


1 


YES 


100 


OTH-T BCST 


OB1000 


0001 


1 


— 


0 



Data precedence processing has been enabled in all 
cases. It is assumed that this practice will be preferred in 
most instances. Recall that in cases where data precedence is 
not enabled and SDUs of equal priority are in contention, PAR 
will be used to determine which SDU will be transmitted first. 

7. Promulgating the Information 

TABLE 6 is an example of how a COMMPLAN might look 
after the initial planning stage. The actual plan will be 
classified so that keying material (keymat) and any other 
classified information can be specified in the plan. 
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(Planners may find it valuable to include other information, 
such as frequencies, at the initial planning step.) The 
priority used here is the theater service priority, or simply 
the COMMPLAN priority. Resource 0002 indicates usage by the 
NCTS for uplinking OTH-T BCST (OB2000) , and by the other NECC 
platforms for receiving OTH-T BCST (OBIOOO) . Note that the 
CSS values (1, Y, 100) for NCTS ' s use of Resource 0002 are 
included. The NCTS might use an available resource for off- 
the-air monitoring of OTH-T BCST (OBIOOO) , as Resource 0001 
illustrates . 



TABLE 5. SERVICE-RESOURCE MATRIX: MULTIMEDIA ACCESS 



SERVICE 


SVC NR 


EHF RESOURCES 




NUMBER 


PRIORITY 


PRECEDENCE 


PAR 


OTH-T COMMS 


OCIOOO 


0001 


1 


YES 


100 




OCIOOO 


0002 


1 


YES 


100 


OTH-T BCST 


OBIOOO 


0002 


1 


— 


0 



In order to be complete, the COMMPLAN promulgated by 
the CCC should contain all networks. Here, HICOM AN DVT is 
included. Its entry denotes that it will use EHF SATCOM and 
requires a non-NECC NESP terminal port. HICOM AN DVT also 
specifies such important information as theater service 
priority, network members and required keymat. 
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As discussed previously, CSS COMMPLANs will be 
promulgated down to lower command levels for review and 
further development. Modifications to theater service 
priority, precedence and PAR values may be made at all levels, 
depending on the platform's outgoing traffic requirements. 
Numbered fleet commanders may add other networks, parameters, 
and frequencies where required, including alternate 
frequencies and the times they are to be used. Battle group 
commanders may add other networks required and match platforms 
to services, assigning additional subscribers to services as 
appropriate. [Ref. 7:p. 23] 

TABLE 6. A SAMPLE CSS COMM PLAN 



SVC NR 


SUBSCRIBERS 


KEYMAT 


EHF RESOURCES 










NR 


PRI 


PREC 


PAR 


OCIOOO 


A,B,C,D,E,F, NCTS , 
CCC 


xxxxxx 


0001 


1 


Y 


100 


OBIOOO 


A,B,C,D,E,F, CCC , 
(NCTS) 


xxxxxx 


0002 


1 




0 


OB2000 


NCTS 


xxxxxx 


0002 


1 


Y 


100 


HI1000 


A,B,C,D,E,F,X,Y,Z 

CCC 


xxxxxx 


' 


1 


" 
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Once he has received the COMMPLAN, the numbered fleet 
commander will review it and make any additions (smaller 
services) , specifying frequencies and times they will be used. 
If there are any problems, he will advise the FLTCINC. The 
numbered fleet commander will also activate an individual 
CNCTNPLAN at his TCC. 

Upon receipt of the COMMPLAN, the battle group 
commander will review it, delete the use of Resource 0002 by 
NCTS , and promulgate the information regarding OTH-T COMMS, 
OTH-T BCST and HICOM ANDVT to the TCCs participating in those 
networks. If the battle group commander identifies any 
problems, he will notify the numbered fleet commander. The BG 
commander will also activate an individual CNCTNPLAN at his 
TCC. 

As discussed previously, resources used from ship to 
ship may differ, and service priority, precedence, and PAR 
values may vary as well. In order to arrive at the ideal 
configuration at his/her own site, each command will follow 
the first three steps of the planning approach: setting up 
services, setting up resources, and matching services to 
resources. 

Upon receiving the COMMPLAN, operators will enter into 
the NECC all pertinent information, based on further 
parameters offered by the EHF Manager within the NECC. (These 
parameters will be based on NESP terminal operations and 
EHF/Milstar satellite and circuit operations [Ref. 16:p. 38].) 
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Once all information is entered, the operator will check the 
site configuration to ensure it complies with the CNCTNPLAN. 
If there are no problems, the CNCTNPLAN will be entered into 
the site's CSS data base, where it will be available for call- 
up, modification if required, and activation at a later time. 
If any problems exist with the site configuration, the 
operator will notify his/her superior for resolution. 

TABLE 7 denotes the CNCTNPLAN of TCC A that has been 
entered into the CSS data base and is ready for activation. 
In this instance, TCC A has assigned service priorities in 
accordance with the CSS COMMPLAN. Should TCC A wish to 
transmit a message to another service member, the CSS would 
provide the status of that member (reachable, unreachable) . 
Note that EHF resources used may differ from site to site. 

TABLE 7. A SAMPLE CNCTNPLAN: TCC A 



SVC NR 


SERVICE 


KEYMAT 


EHF RESOURCES 


NR 


PRI 


PREC 


PAR 


OCIOOO 


OTH-T COMMS 


xxxxxx 


0002 


1 


Y 


100 


OBIOOO 


OTH-T BCST 


xxxxxx 


0002 


1 


— 


0 


HI1000 


HICOM AN DVT 


xxxxxx 




1 







SEW Center personnel should have available the 
CNCTNPLANs of the TCCs within a FLTCINC's AOR in order to 
effectively manage fleet communications. Until the SEW Center 
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comes into being, however, the FLTCINC will remain in control 
of the CNCTNPLANs. He may wish to delegate their management 
to the numbered fleet commander who will, in turn, be 
supported and assisted by the NCTAMS. 

C. CONCLUSION 

Having just taken a closer look at the development of a 
CSS COMMPLAN and CNCTNPLAN, it is now easier to see how a 
CNCTNPLAN could become tailored to the desires and 
requirements of the CWC. Communications will be enhanced by 
CSS multimedia access and resource sharing, making better use 
of resources. The use of service priority, precedence and PAR 
values will further refine use of the resources, allowing the 
CWC, SEWC or shipboard communications officer (COMMO) to 
control the outgoing traffic of a group of TCCs or a single 
TCC . 

TCCs that have a specific mission and transmit large 
volumes of information to support that mission can adjust 
their CSS values accordingly. Services supporting force 
operations or targeting may be assigned higher precedence, 
service priority and PAR values than other services with which 
they share resources. If a platform sends out equal amounts 
of high priority operational and administrative traffic, it 
can modify values to arrive at an optimum mix. These 
practices will ensure that other platforms will receive those 
high precedence, high service priority messages first. 
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Because there are many ways in which to formulate a CSS 
CNCTNPLAN, it is strongly recommended that soon after the 
installation of NECC, ample time be provided for individual 
platforms and groups of platforms to sample and test various 
CNCTNPLAN configurations in order to determine the advantages 
and disadvantages of each one. Testing will enable service 
members to ascertain which configuration (s) provide them the 
most effective and efficient performance to meet their needs. 

As CSS and NECC grow, early development and updating of 
both CSS COMMPLANs and CNCTNPLANs will become necessary. 
Planning and coordination among staffs at different command 
levels are once again stressed. These procedures should 
expedite formulation of the plans. The more CNCTNPLANs that 
exist in a CSS data base, the easier it will be for operators 
to call them up for review, modification (if required) and 
activation. This approach should prevent the need to develop 
any plans from scratch on short notice. 

D . SUMMARY 

A CSS connection plan (CNCTNPLAN) may be considered a set 
of particular services, resources, and values of service 
priority, data precedence and PAR entered into an individual 
CSS site's data base to support an operation. Many types of 
a CNCTNPLAN may exist to support various operations: 
parameters such as service priorities and PARs may vary from 
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theater to theater, from operation to operation, from one 
platform to another, or even from one time period to another. 

CNCTNPLANs will be based on matrices of a future NWP, and 
those matrices will be derived from existing Joint Doctrine, 
theater OPLANs, and COMMPLANs within a FLTCINC's Area of 
Responsibility (AOR) . A CSS COMMPLAN was developed based on 
a proposed planning approach consisting of four steps: 
setting up services, setting up resources, matching services 
to resources, and promulgating the information. 

The first three steps will also be used by each CSS site 
when entering its own CNCTNPLAN into CSS. An example of a 
TCC's CNCTNPLAN was shown based on the COMMPLAN developed and 
promulgated. 
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VI. RECOMMENDATIONS AND CONCLUSION 



A. RECOMMENDATIONS 

1. Planning and Management at CSS/NECC IOC 

Because there are many ways in which to formulate a 
CSS CNCTNPLAN, it is strongly recommended that soon after the 
installation of NECC, ample time be provided for individual 
platforms and groups of platforms to sample and test various 
CNCTNPLAN configurations in order to determine the advantages 
and disadvantages of each one. Testing will enable service 
members to ascertain which configuration (s) provide them the 
most effective and efficient performance to meet their needs. 

As CSS and NECC grow through the incorporation of 

. . . . . . 4 

additional communications systems, contributing to C I more 
proficiently, their planning process will become more complex. 
Although CSS is planned to provide assistance in matching 
services to resources, it is imperative that theater planners 
at all levels become well acquainted with these systems and 
their capabilities. Both operations and communications 
personnel must understand the alternatives that CSS and NECC 
can provide in order to derive the most beneficial use from 
them. It is also necessary that CSS sytem designers must 
provide adequate planning tools to CSS managers in order to 
facilitate their jobs at IOC. 
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This knowledge will also facilitate the development of 
the communications matrices that are to be included in the 
Copernican Naval Warfare Publication (NWP) . It is recommended 
that standardization of CSS service numbers and resource 
numbers occurs during this process. 

2 . NECC 

In Chapter IV, it was suggested that EHF MDR design 
and development continue to completion and that that 
capability be incorporated into the NESP terminal. A recent 
document reflects that the NESP terminal will be modified to 
accommodate EHF MDR on designated ships [Ref. 19 :p. 8-7]. 

3. CSS 

In order for the full benefits of CSS to be realized, 
systems interfacing with CSS should include the full range of 
communications possible for the transmission media being used: 
data, voice, imagery, and/or video-teleconferencing. Only in 
this manner can CSS provide a truly survivable and flexible 
architecture, offering each type of transmission various 
media, or bearer services, by which it can reach its 
destination. 

4. COPERNICUS and CSS 

Finally, the Navy must remain committed to the CSS 
architecture, seeing that it continues to incorporate new 
communications systems as they are developed, regardless of 
any problems that might occur. The worst thing that could 
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happen would be to suspend or cancel incorporation of 

additional communications systems into CSS once it has been 

introduced into the fleet. Termination or delay in expanding 

CSS due to lack of follow-through or lack of funds would 

render it a fragmentary system, having integrated some, but 

not all, communications systems to interface with it. CSS 

must be as comprehensive as possible in order for Copernican 

TADIXS and the COPERNICUS architecture itself to be effective 
2 

C force multipliers. 

B. CONCLUSION 

This thesis has attempted to incorporate all available 
documentation on COPERNICUS, the CSS and the NECC into a 
single text and common language so that it might be used as a 
quick reference by the managers of these systems. By so 
doing, it seeks to familiarize the reader with the functions 
and capabilities of CSS and the NECC, and their relationship 
to the third pillar of the COPERNICUS architecture, TADIXS, to 
which they belong. This thesis has also attempted to provide 
useful recommendations for planning and management of the CSS 
and NECC at IOC. 

It is hoped that the reader has gained a better 
understanding of how CSS and NECC will interact within the 
Copernican architecture to enhance fleet communications and, 
in turn, strengthen and improve C 2 for the CWC, FLTCINC , and 
eventually the USCINC. It is also hoped that operations 
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personnel and communications managers now have a foundation on 
which to plan for CSS and NECC operations prior to IOC. 
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APPENDIX 



NECC Capabilities Summary 



Requirement Description 


Build 1 
(note 2) 


Build 2 
(note 3) 


Build 3+ 


Hardware Sett Test 


X (note 1) 


X 


- 


Auto Startup 


X 


X 




X-Windows Interface 


X 


X 




Connection Plan Generator 


X 


X 




EHF Management Toots 


X 


X 




Trustee Operator Access Control 




X 




On-Sne Help 


X 


X 




On-Line Training And Documentation 


X 


X 




Off-Sne Diagnostics 




X 




EGA (Embedded COMSEC Adaptor) 


X 






MSO (Modular Security Device) 






X 


Voice Packet Service 




X 




Accountable Data Transport 


X 


X 




Reliable Subnet Transport Service 


X 


X 




Reliable End-To-End Transport Service 




X 




Packet Internet 




X 




Multicast Transport 




X 




NSNF Protocol 






X 


KG-64A Link COMSEC 


X 


X 




TOD Link COMSEC 






X 


Embedded UHF SATCOM Control 






X 


DuaJ Redundant Hardware 


X (note 3) 


X (note 4) 




Automatic Fault Recovery 




X (note 5) 




Security Manager 






X (note 6) 



94 



NECC Capabilities Summary (cont’d) 



Requirement Description 


Build 1 
(note 2) 


Build 2 
(note 3) 


Build 2 Option 


TOP Subscriber 


X 


X 




TTY User 






X 


Submarine IXS 






X 


Submarine Reportback 






X 


On-Line Alerts 


X 


X 




Day File Journal 


X 


X 




Performance Monitor 


X 


X 




Configuration Control 


X 


X 




Multimeda Selection 


X (note 3) 


X (note 4) 




Resource Sharing 


X 


X 




Single Beam EHF Subnets 


X 


X 




Multi-Beam EHF Subnets 


X 


X 




Agile Beam Controlled EHF Subnets 






X 


Milstar IBC Interface For Subnet Control 






X 


NESP Terminal Control 






X 


Voice Internet Service 






X (note 5) 


Interoperable Voice Service 






X (note 6) i 


UHF SATCOM Interface 


X 


X 




AN DVT Interface 


X (note 7) 






Voice Subscriber Terminal Interface 




X 




STU-lll Interface 




X 




TADIXS Gateway Interface 


X 


X 




SSIXS Interface 






X 



Note 1 : Build 1 assumes use of SCE Build 1 product 

Note 2: Build 1 assumes use of SCE Build 3 product 

Note 3: Includes VME processor boards only 

Note 4: includes dual redundant mass storage 

Note 5: Limited to mass storage and processor components 

Note 6: Requires use of SCE Build 4 product 
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